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.