-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
404 response for various Node.js downloads and pages #5149
Comments
I only tried one download, but it was a 404 as well. But https://status.nodejs.org/ is all green so I must be HTTPing wrong. 😛 |
More seriously, it's the gzip files that seem broken so far. The "download now" link for me (linux x64) uses the xz file...and that link works. Too bad the asdf plugin for node wants the gz version. (Probably should be using xz anyway) |
@ovflowd The 404 is returning the new 404 page rather than the old nginx one, so I'm not sure if the new build isn't passing through a request correctly /cc @nodejs/build |
The only file that is giving 404 is
Afaik we were always for every 404 within the server returning the Website 404. The only change we made was to also add the 404 to non-https requests. |
@keithlayne actually no, only one file is 404'ing. All other |
@nodejs/build can we check why only |
I noticed that https://nodejs.org/dist/v18.13.0/node-v18.13.0-linux-arm64.tar.xz is 404ing but these versions around it are not: |
@ovflowd I was here becasue of this:
So there are more problems than that one file. |
@keithlayne this seems to be a CloudFlare cache issue. You can check by accessing https://direct.nodejs.org/dist/v16.13.0/ which is the direct connection to our server, and all the links there work normally. I know this doesn't solve your issue, but I'm checking with the team what are our options. |
...and that file just started serving, in the last 15 seconds. |
I can also check that this is being served directly within CloudFlare with
As |
https://direct.nodejs.org/dist/v18.13.0/node-v18.13.0-linux-arm64.tar.xz seems to be working fine. So double-down a CloudFlare cache issue. |
@ovflowd That is really good info, thank you! Looks like I can use that url to solve my current pain. Once I started poking around I was starting to see some CF cache headers. For anyone else who may run into this: NODEJS_ORG_MIRROR=https://direct.nodejs.org/dist/ asdf install nodejs x.y.z seems to work - but let's be responsible, node uses a CDN for a reason. |
Please just a friendly reminder, avoid using direct.nodejs.org when possible. Our server sadly was not designed to handle the load that the web usually does to download Node.js 😅
Exactly! Thank you for your understanding 🙇 |
Thank you for the quick response! |
Seeing similar errors:
|
FYI, we're still monitoring and working on solutions here. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
@walec51 @SiWhite I have purged the cache for those files in all physical locations. (But don't actually use those versions, they have long reached end-of-life status and are unsupported. Even 14.x reaches end-of-life next month.) As I said in my previous comment, some rarely used files, especially those belonging to outdated and unsupported Node.js versions, may be unavailable in some physical locations for a few hours. |
Hey, y'all, as of now, we've done the last fixes that should have handled this incident. We're posting updates on our Status page, and we're going to follow up with a post-mortem afterwards. Thank you! |
Have you changed behaviour of nodejs.org/dist to rate limit and return 403 response code off the back of this incident? (Asking as our CI system is failing due to 403s, not 404s). Note: 403 response code received for HEAD request. |
I don't think we support HEAD requests for nodejs.org/dist. (Correct me if I'm wrong, @nodejs/build) |
In case of confusion: I meant a HEAD request for a full URL to a specific .tar.gz. AFAIK nothing in our CI system has changed (across multiple different projects) |
Is this from Artifactory? There is some filtering being put int place because of problems from a lot of misconfigured instances nodejs/build#3223 |
I'm seeing 403s using Gradle (via faking an Ivy repo) both on CI and on my local development machine trying to hit nodejs.org/dist, and 404s from our Artifactory proxy. |
+1 for the gradle problem reported by @tridium-gward |
Our case was from Gradle too (specifically |
We've just fixed the issue by deploying a new CF Firewall rule. |
I'm still seeing failed builds with respect to Ivy:
|
That's a file that has never existed on the Node.js servers. Suggest you open up an issue on the Ivy plugin, as that would be an issue for their plugin |
@petty Are you creating your own Ivy repo? If so you need to ensure it's configured to only look for artifacts and not metadata (see metadataSources below): repositories {
val nodeRemote = ivy {
name = "NodeRemote"
setUrl("https://nodejs.org/dist")
patternLayout {
artifact("/[revision]/[module]-[revision](-[classifier])(.[ext])")
}
metadataSources {
// This isn't _actually_ an Ivy repo, so it has no metadata
artifact()
}
}
// Ensure the repo is a) only used to resolve org.nodejs and b) no other repos can provide
// any org.nodejs artifacts
exclusiveContent {
forRepositories(nodeRemote)
filter {
includeGroup("org.nodejs")
}
}
} |
Also got the same problem since 17.3.2023:
But also https://nodejs.org/dist/v12.22.6/ returns 500 |
@tomzi8571 as explained by @tridium-gward this is not an issue from our side. This file never existed and with the updated configuration it should now be properly handling the requests. So you have a misconfigured setup of your "Ivy" |
Ok, but this configuration hasn't changed in years ... and this also broke Friday ... |
As a result of triaging this issue, additional blocking rules were setup in nodejs/build#3223. This never worked, but previously didn't hard block as before @petty. This was always a misconfiguration, and won't be rolled back |
To add to @nschonni's explanation, this route likely returned 404 before, and your tooling might have silently ignored that particular error code. The new firewall configuration blocks requests from some misconfigured Artifactory/Gradle setups that would otherwise cause unnecessary load on our infrastructure, resulting in status code 403. |
Ok, all good ... I just needed a newer version of the Gradle Node plugin (specifically moving from 1.3.0 to 1.5.3).
|
The same problem with version: v10.15.3 `What went wrong:
|
@cjiga please, read prior comments before posting here. I'm locking this issue to avoid duplicated comments and pings to the people here. |
URL:
https://nodejs.org/dist/v16.13.0/
Browser Name:
Chrome
Browser Version:
110.0.5481.177
Operating System:
MacOS 12.5.1
How to reproduce the issue:
node-v16.13.0-darwin-x64.tar.gz
from https://nodejs.org/dist/v16.13.0/Using Chome
node-16.13.0-darwin-x64.mov
Using command line
The text was updated successfully, but these errors were encountered: