Re: Proposed HTTP SEARCH method update

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

> On 2015-05-20 08:37, Wenbo Zhu wrote:
>
>> ...
>>     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) ...
>>
>
> Well, it's not. One obvious difference is that it already is defined to be
> safe.
>
>          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.
>>
>
> I still don't see how this affect existing code.
>

If a server chooses to return an unfiltered response to "GET /foo", then
"GET /foo/<random-token>" will return a 404 if the client is concerned
about the GET body being dropped along the way.


>  ...
>>     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.
>>
>
> SEARCH is not a new method. The proposal is about extending it to make it
> useful outside WebDAV.
>
I don't know WebDAV well enough from the standardization/adoption point of
view to comment on this. My own experience is that a new method like SEARCH
(that aims to replace GET) would require a lot of changes.

This of course is not to argue that we should extend GET just because it
involves less changes to the existing Web.

The proposal would do a better job if it articulates the semantic
significance of a new "read" method, in addition to the HTTP detail, IMHO.

E.g. if we believe there are three types of reads in the view of a client:

1. READ: entity known
2. QUERY: entity unknown, response including the entity ids as well as the
content (possibly as partial/templated objects)
3. MONITOR: state changes **

#2 could be called SEARCH. #1 is GET of course, and we will then ask the
Web to migrate all the existing uses of GET for #2 to using SEARCH.

** #3 is effectively Hanging GET. Polling state changes deserve its own
method too.




> Best regards,Julian
>
>
>
>
>
>