Re: Call for Adoption: SEARCH method

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