Re: can GET do for QUERY? extending Partial Content

On 2015-04-29 15:09, henry.story@bblfish.net wrote:
>
>> On 29 Apr 2015, at 14:46, Michael Sweet <msweet@apple.com> wrote:
>>
>> Henry,
>>
>>> On Apr 29, 2015, at 1:35 AM, henry.story@bblfish.net wrote:
>>>>> ...
>>>>> I hope that helps show that this is not an abuse of GET, it just extends
>>>>> existing usage.
>>>>
>>>> You may want to extend but you cannot decide to replace existing products
>>>> which will not comply with your extensions unfortunately. There *are* many
>>>> deployed products which will not cope well with a body in a GET request
>>>> for various reasons and while I agree that from a messaging perspective
>>>> it should not be a problem, from an interoperability perspective it's
>>>> definitely going to be one.
>>>
>>> One shoud be able to verify this. I tested it with the Apache on my server
>>> and it had no problem, even though it knows nothing about the meaning of
>>> GET requests with a body.
>>
>> The CUPS HTTP server will treat a trailing message body in a GET request as a pipelined request since a GET request is not defined to contain a message body (and we have NEVER seen a client do so...)
>>
>> Unfortunately, the wording for this has changed between RFC 2616 and 7230:
>>
>>    [RFC2616 p.33]
>>    The presence of a message-body in a request is signaled by the
>>    inclusion of a Content-Length or Transfer-Encoding header field in
>>    the request's message-headers. A message-body MUST NOT be included in
>>    a request if the specification of the request method (section 5.1.1)
>>    does not allow sending an entity-body in requests. A server SHOULD
>>    read and forward a message-body on any request; if the request method
>>    does not include defined semantics for an entity-body, then the
>>    message-body SHOULD be ignored when handling the request.
>>
>> vs.:
>>
>>    [RFC7230 p.27]
>>    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.
>>
>> i.e., RFC 2616 forbids including a message body for methods that do not define one, while RFC 7230 allows it.
>>
>> I would expect overloading GET in this way to cause interop problems.
>
> Thanks Michael!
>
>    RFC7230 overrides RFC2616, and I suppose HTTP2.0 is in lign with RFC7230.
> So that means in the longer term things should be ok. It may not be wise
> to send GET with a query arbitrarily to web sites right now ( without
> first running tests to find out how big a problem it really is) but over
> time it should become better and better.
>
>    Given that I think we can continue exploring the proposition. The aim
> is to build something that is correct over the long term, that fits well
> with web architecture, that is efficient, etc... This proposal has all
> those advantages.
>
> The advantage over SEARCH [1] are already a few:
>
> 0) that it is clear that the request is scoped to the resource being fetched

To me it's not clear at all.

> 1) that the fallback to GET with query is just GET, which should make sure that the RESTful nature of the web is respected and (0) above is

How would that fallback be helpful?

> 2) that it can function nicely with future enhanced caches, whereas SEARCH does not allow responses to be cacheable

Caching GET+body is exactly as hard as caching SEARCH.

> 3) that in the longer term it will require only 1 connection to a resource to get the quick answer if available, or a full answer if not, whereas SEARCH would always at least require a GET, HEAD or OPTIONS followed by SEARCH  ( unless all SEARCH goes through one mega resource which we want to avoid )

SEARCH doesn't require any HEAD, GET or OPTIONS requests. Also, are you 
confusing "connection" with "number of requests"?

> 4) it does not require a new verb to be created such as QUERY or to build on SEARCH

In one case you update definition of GET, in the other case you update 
the definition of SEARCH. The latter looks much easier (process-wise) 
and disruptive (deployment-wise) to me.

> So I must say I am quite surprised by where last week's reasoning has led me to, given that I started out as a proponent of SEARCH - and even implement my server that way - then moved to thinking about a new verb QUERY, only to find that GET seems to do the job!  :-)
>
> Henry

/me is surprised as well :-)

Best regards, Julian

Received on Wednesday, 29 April 2015 13:26:28 UTC