W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2020

Re: Call for Adoption: SEARCH method

From: James Fuller <jim@webcomposite.com>
Date: Thu, 19 Nov 2020 09:51:33 +0100
Message-ID: <CAEaz5mtYOuEHJyP9H4HD8VyRR5Wj8GkHaYws1iGFFoH3_3vh9w@mail.gmail.com>
To: Greg Wilkins <gregw@webtide.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, 19 Nov 2020 at 09:22, Greg Wilkins <gregw@webtide.com> wrote:
>
>
>
> 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 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.

+1 ... somewhat related - would there by any parity to making a DELETE
with body (allowed today) both safe & idempotent as well ?

James Fuller
Received on Thursday, 19 November 2020 08:51:56 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 19 November 2020 08:51:57 UTC