You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Splitting dist and documentation paths in uri #2376
If you check our nginx config you can see that /dist/, /docs/ and /download/ is more or less identical for these reasons.
I would like to re-introduce dist.nodejs.org (which was a thing in the past) and docs.nodejs.org. The reasons are purely technical (some may have preferences to how url's are designed); it makes it easier for us to do things like traffic shaping and routing. It can open the doors to having docs fully self-maintained and not even tied to our www server.
My main task would be starting with downloads where we would have to consider things like redirecting clients to the new location. I checked in with @ljharb of nvm fame which said that it is already covered with how curl and previously wget was invoked (read: following redirects). @rvagg mentioned that there might be clients that doesn't follow redirects. Does anyone know about use-cases like these?
It's going to be in enterprise workflows where they're using curl without -L, and we're not likely to see them until we break stuff unfortunately! We could do this slow-ish, by first enabling it in parallel to the other options, and then trying the redirect over a weekend, and then trying it over a week where there's a new release, and then turning it on full-time.
We could do this slow-ish, by first enabling it in parallel to the other options, and then trying the redirect over a weekend, and then trying it over a week where there's a new release, and then turning it on full-time.
If we can catch 50% of the traffic, that's a great improvement.
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
Activity
rvagg commentedon Jul 3, 2020
It's going to be in enterprise workflows where they're using
curlwithout-L, and we're not likely to see them until we break stuff unfortunately! We could do this slow-ish, by first enabling it in parallel to the other options, and then trying the redirect over a weekend, and then trying it over a week where there's a new release, and then turning it on full-time.jbergstroem commentedon Jul 3, 2020
If we can catch 50% of the traffic, that's a great improvement.
github-actions commentedon Apr 30, 2021
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.
github-actions commentedon Feb 25, 2022
This issue is stale because it has been open many days with no activity. It will be closed soon unless the stale label is removed or a comment is made.