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

Max Leske maxleske at gmail.com
Tue Aug 3 17:08:28 UTC 2021


On 3 Aug 2021, at 0:18, Esteban Maringolo wrote:

> 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?

That sounds right to me. By "retry performing a regular GET request as a fallback" you mean running the handler for a GET request for that route but return only the headers, right? I wonder how that is handled at the moment. Is the body being discarded after having been assembled? There's probably no other way, as you have to know the data you would be sending (e.g., for Content-Length).

Cheers,
Max

>
> 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
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20210803/ae76d9ab/attachment.sig>


More information about the seaside-dev mailing list