HEAD requests are not available

[pimvanpelt]

Description

Not sure if this is a bug or working as intended, but I have noticed that TesseraCT (at least the POSIX one) does not implement HEAD requests, only POST and GET:

Compare:

$ curl -Ssv  https://halloumi2025h2.log.ct.ipng.ch/ct/v1/get-roots -o /dev/null
...
< HTTP/2 200 
< server: nginx/1.26.3
< date: Wed, 27 Aug 2025 21:03:22 GMT
< content-type: text/plain; charset=utf-8
< vary: Accept-Encoding
< x-ipng-frontend: nginx0-chrma0
< 
{ [8060 bytes data]

With:

$ curl -ISsv  https://halloumi2025h2.log.ct.ipng.ch/ct/v1/get-roots -o /dev/null
< HTTP/2 405 
< server: nginx/1.26.3
< date: Wed, 27 Aug 2025 21:04:10 GMT
< content-type: text/plain; charset=utf-8
< content-length: 44
< x-content-type-options: nosniff
< x-ipng-frontend: nginx0-chplo0
< 
{ [0 bytes data]

This is not a frontend issue, hitting the IPv4 / IPv6 endpoint directly yields the same result:

ctlog@ctlog1:~$ curl -I  localhost:16900/ct/v1/get-roots 
HTTP/1.1 405 Method Not Allowed
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Date: Wed, 27 Aug 2025 21:05:52 GMT
Content-Length: 44

ctlog@ctlog1:~$ ps auxw | grep 16900
ctlog      51635  2.3  0.2 4418792 45844 ?       Ssl  Aug26  52:54 /home/ctlog/bin/tesseract-posix --private_key=/ssd-vol0/enc/tesseract/keys/lipase2025h2.pem --origin=lipase2025h2.log.ct.ipng.ch --storage_dir=/ssd-vol0/logs/lipase2025h2/data --roots_pem_file=/ssd-vol0/logs/lipase2025h2/data/roots.pem --http_endpoint=[::]:16900 --not_after_start=2025-07-01T00:00:00Z --not_after_limit=2026-01-01T00:00:00Z

Perhaps we can consider documenting that HEAD requests are ineffective in TesseraCT, or update it to implement HEAD requests.

[pimvanpelt]

Incidentally, it's not just POSIX, the Google staging log also rejects these requests

pim@glootie:~$ curl -I https://arche2025h1.staging.ct.transparency.dev/ct/v1/get-roots 
HTTP/2 405 
content-type: text/plain; charset=utf-8
x-content-type-options: nosniff
date: Wed, 27 Aug 2025 21:09:55 GMT
content-length: 44
via: 1.1 google
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

[roger2hk]

Thanks for reporting this. I believe this is working as intended. Both RFC 6962 and static-ct-api specification do not mention anything related to HEAD requests. Note that the Trillian/CTFE implementation also does not support the HEAD method request.

➜  ~ curl -I https://ct.googleapis.com/logs/us1/argon2025h2/ct/v1/get-roots
HTTP/2 405 
content-security-policy: sandbox allow-downloads allow-forms allow-modals allow-orientation-lock allow-pointer-lock allow-popups allow-popups-to-escape-sandbox allow-presentation allow-scripts allow-storage-access-by-user-activation allow-top-navigation allow-top-navigation-by-user-activation allow-top-navigation-to-custom-protocols
content-type: text/plain; charset=utf-8
cross-origin-opener-policy: same-origin
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-xss-protection: 0
date: Wed, 27 Aug 2025 21:18:40 GMT
content-length: 44
alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000

However, I think it makes sense to support HEAD request in the standard HTTP practice providing the efficiency of resource/cache verification.

If you're using NGINX and would like to have the workaround to support HEAD requests at the moment, I would suggest adding the NGINX configuration to transform the incoming HEAD request into a GET request and then discard the response body and send only the headers back to the client.

[pimvanpelt]

Followup - it's not an operational issue so I will not be configuring IPng's nginx to synthesize the HEAD request.
Feel free to close the report if this is WIP and not an issue for others (in the last 3mo certainly nobody signaled an interest).