Re: Proposed HTTP SEARCH method update - QUERY is to GET what PATCH is to PUT

> On Apr 27, 2015, at 10:29 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 2015-04-28 00:41, henry.story@bblfish.net wrote:
>> 
>>> On 27 Apr 2015, at 22:49, Julian Reschke <julian.reschke@gmx.de> wrote:
>>> 
>>> On 2015-04-27 22:34, henry.story@bblfish.net wrote:
>>>> ...
>>>> It is my feeling that the authors of this draf want to do the right thing here, but were worried
>>>> to come up with a new method name, and favored going with something existing like SEARCH rather
>>>> than try something new. I was hoping in the previous mail that SEARCH could be redefined to do
>>>> the right thing. But if it cannot then another method name is welcome.
>>>> ...
>>> 
>>> There are already three safe HTTP methods that take a request payload (PROPFIND, SEARCH and REPORT). Some software stacks already know about these (for instance, wrt whether a request can be safely repeated on network failure). There's simply no reason to create yet another one, when, from an HTTP point of view, it does exactly the same thing.
>> 
>> I think the disagreement is that SEARCH does what we need. To quote Roy Fielding's
>> answer:
>> 
>>  " In both of those definitions, SEARCH was not a method that scoped its results
>>    to the requested URI.  That URI, in fact, had almost nothing to do with the
>>    results, making implementation of the method a significant security risk. "
> 
> Well, Roy is overstating things. That particular usage pattern depends on the query grammar, and is totally optional in the only grammaer defined in RFC 5323; see <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.4>.

That is scoping by the message body, not by the method semantics.  The difference is
that the request target contains essential bits for routing a request within (or behind)
the origin server, so if a special route is applied to, for example, a path within the
URI, then we want the method semantics to be limited to the scope of that path.
If the scope is not limited by the method, then implementation gets very messy.
[POST might have remained limited in that way as well, but the introduction of forms
made its original semantics irrelevant, so there wasn't much point in scoping them.]

Routing can't parse the request body for routing information because that would assume
all resources are the same and the body is going to be processed instead of responding
with 401, 403, or some other error code usually determined by path.

....Roy

Received on Tuesday, 28 April 2015 16:29:46 UTC