Re: can GET do for QUERY? extending Partial Content

> 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
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
2) that it can function nicely with future enhanced caches, whereas SEARCH does not allow responses to be cacheable
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 )
4) it does not require a new verb to be created such as QUERY or to build on SEARCH 

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

[1] as proposed for example by draft-snell-search-method 
   http://datatracker.ietf.org/doc/draft-snell-search-method/?include_text=1

> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 

Social Web Architect
http://bblfish.net/

Received on Wednesday, 29 April 2015 13:10:15 UTC