Docker Repo: Bad Request (400) after upgrade from 3.58.1 -> 3.59.0

Sonatype Nexus Repository
1

Hi

I’m hitting a strange issue where following an upgrade from 3.58.1 → 5.59.0 I cannot access my docker repo. Reverting back to 3.58.1 all works again. My repo is configured to use a specific port and uses an apache reverse proxy. Bypassing the proxy does nothing to change the outcome, so the issue is clearly within nexus.

To test I’m hitting my server with curl and I’m expecting 404 response (invalid URL - this is my test), as you can see following the upgrade, I get a response from Jetty(9.4.51.v20230217), not Nexus/3.59.0-xx (OSS) as you’d expect?

Any suggestions?

Many thanks!

3.58.1 (working request), ie I get an expected (404) response from Server: Nexus/3.58.1-02 (OSS)

$ curl -I http://192.168.200.111:58001/repository/mydocker/
HTTP/1.1 404 Not Found
Server: Nexus/3.58.1-02 (OSS)
X-Content-Type-Options: nosniff
Content-Security-Policy: sandbox allow-forms allow-modals allow-popups allow-presentation allow-scripts allow-top-navigation
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Expires: 0
X-Frame-Options: DENY
Content-Type: text/html
Content-Length: 1518

3.59.0 (broken), ie I get an unexpected (400) response from Server: Jetty(9.4.51.v20230217)

curl -I http://192.168.200.111:58001/repository/mydocker/
HTTP/1.1 400 Bad Request
Cache-Control: must-revalidate,no-cache,no-store
Content-Type: text/html;charset=iso-8859-1
Content-Length: 503
Server: Jetty(9.4.51.v20230217)
2

If 58001 is a Docker connector port configured on a specific repository you should only access Docker endpoints through it, not general Nexus paths is appears to be the case.

3

Many thanks for the feedback. My cURL commands were just a method to test/visualise the HTTP/S response, as when using “docker login” and/or “docker pull” it would error with “bad response” and nothing more.

I also tested creating a new docker repo against a new port (5802) but the same error manifests going via my reverse proxy (apache) or direct connection to the nexus3 docker container.

I’m beginning to wonder if enabling v1 support (legacy) support is worth a go and/or whether something has changed in docker CLI meaning my configuration when upgraded to nexus3 3.59.+ is causing an issue.

Screenshot 2023-10-07 103021
Screenshot 2023-10-07 1030212070×2030 234 KB

4

I believe we changed some of the responses when accessing non-docker APIs via Docker connector ports (or if Pro and using subdomain connectors).

If you’re trying to access real Docker APIs with cURL you may need to emulate client behaviour as headers are import for Docker.

5

hey @mpiggott after some wrestling with this, I think* it was a proxy path issue - many thanks for the pointers!

Unless I’m horribly mistaken, and I’m getting false positives, it turned out that my working prox config (Nexus3:3.58.1) and earlier worked with (using apache/httpd as my reverse proxy)

       ProxyPass / http://192.168.200.111:58101/repository/<reponame>/ nocanon
       ProxyPassReverse / http://192.168.200.111:58101/repository/<reponame>/

but for nexus3 v3.59.0 and later (ie v3.70.1) this seems to work:

       ProxyPass / http://192.168.200.111:58101/ nocanon
       ProxyPassReverse / http://192.168.200.111:58101/

There’s a behaviour change between versions, but does my resolve/understanding look/sound right to you?

Many thanks!