Support HEAD requests

[lf-]

Is your feature request related to a problem? Please describe.

s3-proxy returns 405 errors for HEAD requests. This breaks various clients which want to determine the content type of a file or how large it is or similar information.

~ » curl --head https://install.lix.systems/install
HTTP/2 405
server: nginx
date: Sun, 18 Aug 2024 21:36:43 GMT
allow: GET
cache-control: no-cache, no-store, no-transform, must-revalidate, private, max-age=0
expires: Thu, 01 Jan 1970 00:00:00 GMT
pragma: no-cache
vary: Origin

I have inspected the config documentation here: https://oxyno-zeta.github.io/s3-proxy/configuration/structure/#actionsconfiguration and I do not think there is a way to enable it.

Describe the solution you'd like

Support HEAD requests per the HTTP spec.

Describe alternatives you've considered

There is not any real alternative to this, maybe a range of 0 to 0 or something but that is not entirely clear whether that works.

Additional context Add any other context or screenshots about the feature request here.

[oxyno-zeta]

Hello @lf- ,

Sorry for being late on this.

I see the issue and I'm afraid that this isn't supported (yet). I will check how to do it. Thanks for the issue.

Oxyno-zeta

[stefan-korchahin]

Hi, is any ETA of implementation this feature?

[oxyno-zeta]

Hi,

I'm sorry but I don't have any ETA for this.

For me, there are 2 possible solutions:

• Change the GET code to manage HEAD requests by adding code branching where it is needed to change the end query to S3 or to change the way we are answering (headers template, etc etc)
• Create a totally new function to manage this case

After that, there is another question: Can we use the same configuration as the GET one for header templates, etc or do we need to create a new and different section ?

I've started something "on my computer" but I'm not a big fan of it and I don't have a lot of time those days sorry. For the moment, I'm searching the "best" solution to implement this.

Oxyno-zeta

[lf-]

fwiw we worked around it by just using the garage http server for the affected domain so it's not a hurry for us at all.

it's most likely most correct to treat it as a special GET that returns no data both in terms of config and in terms of code. though, stuff like directory listings may possibly want to refuse HEAD requests because that sounds like a big pain. i wonder what forgejo and other web apps do for HEAD on their templated pages.

[oxyno-zeta]

Hello,

I've started something. The code is working well as far as I can see but tests aren't finished. I need some time to finish integration tests on this new code and also documentation. This is a work in progress.

[oxyno-zeta]

Sorry for the auto close without a comment. It is due to merge on master...

This is finished and on master branch. This will be released in the next version. I want to work on few other details before releasing a new version.

Thanks for your issue !

[stefan-korchahin]

Sorry for the auto close without a comment. It is due to merge on master...

This is finished and on master branch. This will be released in the next version. I want to work on few other details before releasing a new version.

Thanks for your issue !

thanks a lot for your work and fast resolution🤝

[lf-]

Thank you!!

[oxyno-zeta]

:tada: This issue has been resolved in version 4.17.0 :tada:

The release is available on:

• GitHub release
• v4.17.0

Your semantic-release bot :package::rocket:

[oxyno-zeta]

Hello,

As you can see with the semantic-release bot, this has been released in 4.17.0 version :) .

Those operations have to be enabled to work. By default, they are disabled. All headers and answer template are the GET request ones. Hope it will solve your issue ! Thanks again for your enhancement request. This was a very good feature to add.

Have a nice day,

Oxyno-zeta

[stefan-korchahin]

could you share please, some info, about how to enable support of HEAD method? I'm using helm chart Am I need some additional configurations? something like this:

                    actions:
                      GET:
                        enabled: true
                      HEAD:
                        enabled: true

because after deploying new version, in logs see this:

time="2024-09-24T07:39:31Z" level=error msg="request complete" http_method=HEAD http_proto=HTTP/1.1 http_scheme=https req_id=2de6562c41ea8446fb13c63df8e06a81 resp_bytes_length=0 resp_elapsed_ms=0.12679 resp_status=405 uri="https://my.domain.com/files/sendinblue-csv/242288040.csv" user_agent=curl/8.4.0

[oxyno-zeta]

It should be enough.

Can you share me your helm values ? Or better, can you port-forward to the 9090 port and call the /config endpoint to see if your configuration is well seen by the application ? See here: https://oxyno-zeta.github.io/s3-proxy/feature-guide/internal-api/#config

[stefan-korchahin]

HEAD: enabled: true

I mean, am I need to set in config HEAD method support? or HEAD method works alongside with just enabled GET requests? Because I'm not configured

                      HEAD:
                        enabled: true

[stefan-korchahin]

It should be enough.

Can you share me your helm values ? Or better, can you port-forward to the 9090 port and call the /config endpoint to see if your configuration is well seen by the application ? See here: https://oxyno-zeta.github.io/s3-proxy/feature-guide/internal-api/#config

from /config route

[oxyno-zeta]

You should have this: If you haven't, then it won't work.

Can you share me the full values please ? I think you have a wrong indent in it.

[stefan-korchahin]

Owner

          values: |
            envFrom:
              - secretRef:
                  name: s3-access
            configFiles:
              config.yaml:
                log:
                  level: debug
                  format: text
                targets:
                  uploads-test-files:
                    mount:
                      path: /files/
                    actions:
                      GET:
                        enabled: true
                      HEAD:
                        enabled: true
                    bucket:
                      name: uploads-test-files
                      prefix: /files/
                      region: eu-central-1
                      disableSSL: false
                      credentials:
                        accessKey:
                          env: AWS_ACCESS_KEY_ID
                        secretKey:
                          env: AWS_SECRET_ACCESS_KEY
                        region:
                          env: AWS_DEFAULT_REGION

[stefan-korchahin]

But my developer says that now it working(that's strange), It seems when I added HEAD enabled for bucket, but config still shows that HEAD method not enabled.. that's strange

[oxyno-zeta]

Your values seem correct so I guess that was a transient upgrade error.

Cool if it is working now :) !