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

[Max Leske]

Great, thanks!

On 2 Aug 2021, at 21:56, Esteban Maringolo wrote:

> Hi!
>
> OPTIONS has been there for a while, and I've been using it to handle
> CORS preflight requests (I'll publish my filter this week, as per this
> PR [1])
>
> Best regards!
>
> [1] https://github.com/SeasideSt/Seaside/issues/1270
>
> Esteban A. Maringolo
>
> On Mon, Aug 2, 2021 at 4:49 PM Max Leske <maxleske at gmail.com> wrote:
>>
>> Great! I haven't checked, maybe the OPTIONS header needs to be added as well?
>>
>>
>>
>> On 2 Aug 2021, at 21:46, Esteban Maringolo wrote:
>>
>>> Hi Max,
>>>
>>> I don't use it, and don't see the real need other than to give the
>>> developer full control of the routes.
>>>
>>> I'll submit a PR to include HEAD as possible route methods in the
>>> WARouteBuilder. I'll use the chance to add support for PATCH as well
>>> :-)
>>>
>>> Regards!
>>>
>>> Esteban A. Maringolo
>>>
>>> On Mon, Aug 2, 2021 at 4:37 PM Max Leske <maxleske at gmail.com> wrote:
>>>>
>>>> Hi Esteban,
>>>>
>>>> I don't see why it shouldn't be possible to handle HEAD requests explicitly. I think it's a good idea to have the option (even though most people won't need and shouldn't use it).
>>>>
>>>> Cheers,
>>>> Max
>>>>
>>>>
>>>> On 2 Aug 2021, at 21:33, Esteban Maringolo 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
>>>> _______________________________________________
>>>> seaside-dev mailing list
>>>> seaside-dev at lists.squeakfoundation.org
>>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>> _______________________________________________
>>> seaside-dev mailing list
>>> seaside-dev at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>> _______________________________________________
>> seaside-dev mailing list
>> seaside-dev at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
> _______________________________________________
> 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/eae940d1/attachment.sig>