When proxying to Jitpack via Nexus Repository Manager, a request for a non-existent artifact file results in an empty 200 response rather than a 404 i.e.
curl -I https://jitpack.io/com/foo/bar/maven-metadata.xml -H 'User-Agent: Nexus/3.18' --http1.1
HTTP/1.1 200 OK
Date: Mon, 16 Sep 2019 11:38:30 GMT
Content-Type: text/plain;charset=UTF-8
Connection: keep-alive
Set-Cookie: __cfduid=d9d7b69063b448847bda55aa5be98e5261568633910; expires=Tue, 15-Sep-20 11:38:30 GMT; path=/; domain=.jitpack.io; HttpOnly
Cache-Control: no-cache, no-store, must-revalidate
X-Jp-Cf: 2
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 51728df62d95dc2b-LHR
This can cause build failures downstream. The expected response is a 404.
No user-agent string results in the expected response:
curl -I https://jitpack.io/com/foo/bar/maven-metadata.xml --http1.1
HTTP/1.1 404 Not Found
Date: Mon, 16 Sep 2019 11:10:58 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 0
Connection: keep-alive
Set-Cookie: __cfduid=df9d13532b3504c0982fb94e9fa48f1991568632258; expires=Tue, 15-Sep-20 11:10:58 GMT; path=/; domain=.jitpack.io; HttpOnly
Server: cloudflare
I got another error: https://github.com/jitpack/jitpack.io/issues/3978, but I request existent artifact.
Just got the same problem with empty responses resulting in zero sized pom artefacts in Nexus and breaking builds behind. Maybe it is a misconfiguration or rate limiting by cloudflare? Actually the nexus proxies help to lower request rates and should be an appreciated setup.
We had the same issue today, costed way too long to track down (because, well, such a thing was completely unexpected and we suspected the ops team breaking something after a planned maintenance over the weekend). I opened up a ticket on Sonatype's tracker as well, because I think Nexus could have had _some_ countermeasure for big f*ups like this: https://issues.sonatype.org/browse/NEXUS-21155
Seeing the same issue here. Wasted a lot of developers time trying to figure out what was going on.
Perhaps the workaround is to change the User-Agent via https://help.sonatype.com/repomanager3/configuration/system-configuration#SystemConfiguration-HTTPandHTTPSRequestandProxySettings
For now, I've shunted jitpack.io's configuration in my Nexus to localhost. Might give the user-agent change a try tomorrow... just don't want to interrupt development and builds after this morning's fiasco.
Hi,
Should be fixed now.
Thanks. Yes looks to be working as expected now:
curl -I https://jitpack.io/com/foo/bar/maven-metadata.xml -H 'User-Agent: Nexus/3.18' --http1.1
HTTP/1.1 404 Not Found
...
Attention anybody using Nexus. You can construct a query that finds all the 0 byte artifacts in your system.
jitpack where I work)d41d8cd98f00b204e9800998ecf8427e; this is the "empty MD5" (if you don't believe me, you can run echo -n '' | md5sum)What I did with these results was click each of them, make sure the files inside were generated between Sept. 14th and today, then click "Delete Component". Do this, and you'll have removed all of these nuisance dependencies so you don't have to deal with this ever again (assuming Jitpack itself doesn't regress).
Most helpful comment
Attention anybody using Nexus. You can construct a query that finds all the 0 byte artifacts in your system.
jitpackwhere I work)d41d8cd98f00b204e9800998ecf8427e; this is the "empty MD5" (if you don't believe me, you can runecho -n '' | md5sum)What I did with these results was click each of them, make sure the files inside were generated between Sept. 14th and today, then click "Delete Component". Do this, and you'll have removed all of these nuisance dependencies so you don't have to deal with this ever again (assuming Jitpack itself doesn't regress).