Re: Proposed HTTP SEARCH method update

On Tue, May 19, 2015 at 11:09 PM, Julian Reschke <
julian.reschke@greenbytes.de> wrote:

> On 2015-05-20 00:08, Wenbo Zhu wrote:
>
>>
>>
>> On Sun, May 3, 2015 at 11:45 PM, Philippe Mougin <pmougin@acm.org
>> <mailto:pmougin@acm.org>> wrote:
>>
>>
>>      > Le 10 avr. 2015 à 18:00, James M Snell <jasnell@gmail.com
>>     <mailto:jasnell@gmail.com>> a écrit :
>>      >
>>      > Please see:
>>     http://datatracker.ietf.org/doc/draft-snell-search-method/
>>      >
>>      > Comments welcome.
>>      >
>>      > - James
>>      >
>>
>>     James,
>>
>>     I think the introduction chapter fails to correctly characterize the
>>     way GET is commonly used to support search operations.
>>
>>     The draft gives an example
>>     ("http://example.org/feed?q=foo&limit=10&sort=-published") and
>>     states: "The path identifies the resource processing the query (in
>>     this case 'http://example.org/feed') while the query identifies the
>>     specific parameters of the search operation."
>>
>>     This description recasts the Web model into an RPC-like system where
>>     the http://example.org/feed resource is a little bot we send
>>     parameters to in order for it to perform a search.
>>
>> +1
>>
>> SEARCH with a body feels as bad as "X-HTTP-Method-Override" alike (when
>> one has to work around the URL encoding limit to turn a GET into POST),
>> and neither will be safely retried or cached, yet.
>>
>
> SEARCH can be safely retried, and some pieces of code already know that.
>
> Also: X-HTTP-Method-Override is a hack people used when they couldn't use
> new methods (for some value of "new"). Why does *not* using this hack feel
> to you like doing it? /me confused.

SEARCH to me is like a POST, i.e. to make a function call against a
resource. This is what I was suggesting (or voting) ...

>
>
>  GET with a body: to ensure no server will ignore the body, could we
>> expect the client to generate a unique token in the URL? Also, I think
>>
>
> a) How is this supposed to work? b) Even if it did, how is mangling things
> into the URL ever a good idea?

To address the concern that a server that does not look at the GET body may
return an unfiltered resource based on just the URL.

If a client doesn't care about body being ignored, then there is no need to
mingle the URL.


>
>
>  the C-T alone will be sufficient to categorize a GET as a search
>> request, by supported proxies/servers.
>>
>
> Yes, if you rewrite all components that currently do not expect GET with
> bodies.
>
If we can address the safety issue, then I believe GET + body complicates
the Web less than introducing a new method like SEARCH (whose use cases
overlaps with GET in many ways), IMHO.


> > ...
>
> Best regards, Julian
>
>