Re: Call for Adoption: SEARCH method

On Thu, 19 Nov 2020 at 05:49, Julian Reschke <julian.reschke@gmx.de> wrote:

> Am 19.11.2020 um 04:39 schrieb James M Snell:
> > To be clear, this is not intended as a safe, idempotent equivalent to
> > POST. It is intended specifically to cover search/query operations which
> > are often ambiguously represented as GET or POST. I'm not quite sure
> > what a safe idempotent equivalent to POST would even be, but this is not
> > it.
> > ...
>
> FWIW, I disagree with that. Ignore the method name for a moment, and
> what's left is a retrieval operation similar to GET which additionally
> takes the request payload into account.
>


Then why don't we just define the semantics of  GET's may have bodies.   I
think this would be trivial for most implementations and that many already
do support it, given that RFC7230 3.3
<https://tools.ietf.org/html/rfc7230#section-3.3> says:

>    The presence of a message body in a request is signaled by a
>    Content-Length or Transfer-Encoding header field.  Request message
>    framing is independent of method semantics, even if the method does
>    not define any use for a message body.


Then in RFC7231 4.3.1 <https://tools.ietf.org/html/rfc7231#section-4.3.1>
it says:

>    A payload within a GET request message has no defined semantics;
>    sending a payload body on a GET request might cause some existing
>    implementations to reject the request.


So let's just save the carbon footprint of creating another method (and
enforcing that GET's cannot have bodies) by defining the circumstances in
which a body of a GET can have semantic significance?    I don't see that
as contrary to 7230 and is not prohibited by 7231.

For most implementations, this will just work as they don't care about the
method when handing message framing.   For implementations that actually
handle the method, I see very less work to allow bodies to GETs (which many
probably already do) that to add a new method and all the framework
apparatus that implies and all the tests and new CIs and wasted
CPU/developer cycles for something that is already mostly there.

A client that wishes to send a SEARCH or a GET with a body will equally
have to expect a 4xx if something in the path doesn't expect either.   The
main difference is that a GET with a body may receive a response that
simply ignored the body and the client may not be able to determine that.
But then equally it is not possible to tell if a SEARCH method has been
simply routed to a GET implementation and the body equally ignored.   If
this is a concern, then perhaps defining a response header that indicates
the request body was considered is a better way forward?

cheers










-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com