[Seaside-dev] HEAD HTTP method handling in RESTful handlers/filters

[Esteban Maringolo]

Giving a second thought to this, I find that handling HEAD in a
RESTful handler will cause a 404 when there is no route implemented
for HEAD as method, which is wrong, since the HEAD should work the
same for any resource defined as GET as well.

I think that a HEAD request should first attempt to find a specific
route matching it, and if not then it should retry performing a
regular GET request as a fallback, and then if there is no route
return 404 or whatever status is needed.

Am I overthinking this?

Esteban A. Maringolo

On Mon, Aug 2, 2021 at 4:33 PM Esteban Maringolo <emaringolo at gmail.com> wrote:
>
> Hi,
>
> As per the RFC the HEAD is identical to a GET but without the body,
> but given you might want to have full control of all requests coming
> to your REST handler, it might be the case you want to answer HEAD
> methods differently (e.g. to avoid serializing things and/or reading
> them from the DB).
>
> For some reason the HEAD HTTP method is not available as method in
> WARouteBuilder, so it is not possible to have a specific HEAD handling
> for a certain route.
>
> Does it make sense not having HEAD support as a possible method for a route?
> Having HEAD returning different headers to that of a common GET would
> make it not compliant?
>
> This might require not only implementing the configuration pragma in
> the WARouteBuilder, but also modifying the WAServerAdaptor to forward
> native HEAD requests to the handlers.
>
> Regards!
>
> Esteban A. Maringolo