Skip to content

Disable HEAD conversion for the api nginx location config

David Fernandez requested to merge 7480-nginx-stop-converting-head-requests into master

🌴 Context

In Investigate: Maven repository not working with ... (gitlab#381504 - closed), we found out that nginx in omnibus is convert HEAD requests into GET requests for urls on api/v4/*.

This introduces a typebug as we have API endpoints that behaves differently if a GET or a HEAD is received.

One impacted area is the Maven package registry with the $ gradle client targeting a omnibus GitLab instance that uses AWS S3 as its object storage backend.

More details in nginx changes HEAD requests into GET requests (#7480 - closed) and gitlab#381504 (comment 1297755108)

🤔 What does this MR do?

Update the location ~ ^/api/v\d config block of files/gitlab-cookbooks/gitlab/templates/default/nginx-gitlab-http.conf.erb to avoid converting HEAD requests into GET requests.

⛓ Related issues

nginx changes HEAD requests into GET requests (#7480 - closed)

⚙ How to test this locally

  1. Setup an omnibus according to https://gitlab.com/gitlab-org/omnibus-gitlab/-/blob/master/doc/development/setup.md.
  2. Setup object storage for packages on AWS S3 according to https://docs.gitlab.com/ee/administration/object_storage.html#use-aws-s3
    • Make sure that gitlab_rails['object_store']['proxy_download'] is set to false.
  3. $ gitlab-ctl reconfigure

Let's upload a dummy package file to the generic package registry. It's not a Maven package but we're going to use the same requests that $ gradle uses with $ curl

$ curl --header "PRIVATE-TOKEN: <pat token>" --upload-file ./dummy.txt "http://<whatever base url>/api/v4/projects/<project id>/packages/generic/awesome_package/1.3.7/file.txt" 
{"message":"201 Created"}

We're now ready.

💥 With master

Let's try to HEAD the file:

$ curl -L --head --header "PRIVATE-TOKEN: <pat>" "http://<whatever base url>/api/v4/projects/<project id>/packages/generic/awesome_package/1.3.7/file.txt"
HTTP/1.1 302 Found
Server: nginx
Date: Thu, 02 Mar 2023 17:11:55 GMT
Content-Type: text/plain
Content-Length: 491
Connection: keep-alive
Cache-Control: no-cache
Location: XXX
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 01GTHMY3DCKE8G4JFRDT2KT3B2
X-Runtime: 2.519037
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

HTTP/1.1 403 Forbidden
x-amz-request-id: XJTQBJD1ZSJNW4Y5
x-amz-id-2: pQ8ibAQkh5MShoAmzAOCW4H889AkQdOKLeyVjEsB5Kf9JePrv0AggzCupcOE2A37gME3WVduqPc=
Content-Type: application/xml
Date: Thu, 02 Mar 2023 17:11:56 GMT
Server: AmazonS3

It doesn't work (S3 says 403 Forbidden).

🚒 With this MR

⚠ Don't forget to gitlab-ctl reconfigure.

Let's HEAD the file again:

$ curl -L --head --header "PRIVATE-TOKEN: <pat>" "http://<whatever base url>/api/v4/projects/<project id>/packages/generic/awesome_package/1.3.7/file.txt"
HTTP/1.1 303 See Other
Server: nginx
Date: Thu, 02 Mar 2023 17:15:36 GMT
Content-Type: text/plain
Connection: keep-alive
Cache-Control: no-cache
Location: XXX
Vary: Origin
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Request-Id: 01GTHN4VBTD17YBP6TQZ4267TE
X-Runtime: 3.257612
Strict-Transport-Security: max-age=63072000
Referrer-Policy: strict-origin-when-cross-origin

HTTP/1.1 200 OK
x-amz-id-2: ATSSLo+G1w8K75DltRqPV1a5BxpKDUgw5PBeXSIHvt4lmFUifvEvwFYlyORRmzvSyNWLzDynqkZl2rV+kta8JA==
x-amz-request-id: G343FWA2QPTZ691F
Date: Thu, 02 Mar 2023 17:15:42 GMT
Last-Modified: Thu, 02 Mar 2023 17:09:24 GMT
ETag: "3e242fb714d87b3c110c86476f5ff972"
x-amz-server-side-encryption: AES256
Accept-Ranges: bytes
Content-Type: binary/octet-stream
Server: AmazonS3
Content-Length: 8

Success! (S3 accepts the request and serves the file) 🎉

🚥 Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

  • Merge Request Title, and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com
  • Pipeline is green on dev.gitlab.org if the change is touching anything besides documentation or internal cookbooks
  • trigger-package has a green pipeline running against latest commit

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • [-] Documentation created/updated
  • Tests added
  • Integration tests added to GitLab QA
  • Equivalent MR/issue for the GitLab Chart opened

Merge request reports