Re: can GET do for QUERY? extending Partial Content

> On 29 Apr 2015, at 15:25, Julian Reschke <> wrote:
> On 2015-04-29 15:09, wrote:
>>> On 29 Apr 2015, at 14:46, Michael Sweet <> wrote:
>>> Henry,
>>>> On Apr 29, 2015, at 1:35 AM, 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.

It has to as per definition of GET .

>> 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?

Because since the client is only interested in download speed optimisation with the with GET + Query proposal - the client wants to get at some part of the information quickly - then if he receives instead the full document he still gets the information, just not as fast.

>> 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.

In draft-snell-00 it says "The response to a SEARCH request is not cacheable." 
And in our discussions this week I did not see any movement on that point, though I questioned it.
So it looks rather that caching is impossible with SEARCH but built in to GET.

>> 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"?

yes, sorry, it requires one more request. 

That is important though. If you count the fastest clock cycle of a CPU and map it to the fastest human clock cycle, say 1 second, then the time it would take on that frame of reference to send a packet from California to Europe and back would be 4 years. I am saying this to help get an idea of the latency differences between in CPU cache memory access and going over the web.

Extra requests are wasteful and should be avoided.

>> 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.

We're not proposing to updating GET, just enhancing the existing Partial Content feature. 

>> 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 :-)

I let myself be driven by where arguments lead me to :-)

> Best regards, Julian

Social Web Architect

Received on Wednesday, 29 April 2015 13:43:57 UTC