Re: can GET do for QUERY? extending Partial Content

On 2015-04-29 15:43, henry.story@bblfish.net wrote:
>
>> On 29 Apr 2015, at 15:25, Julian Reschke <julian.reschke@gmx.de> wrote:
>>
>> 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.
>
> It has to as per definition of GET .

As far as I can tell, scoping for GET and SEARCH is exactly the same, 
except that in SEARCH, the scope can be defined in the body (not only 
the URI or request header fields).

I gave the example of a GET on google.com; can you explain what the 
material difference is?

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

If you consider a query to be just a speed optimization compared to 
"getting all", sure. I don't how that's helpful though.

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

It's a draft. And caching of responses to GET request with bodies would 
need to be both defined and implemented as well. It's a change to the 
standard HTTP caching model (so good luck with that...).

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

Which?

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

See above.

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

"A payload within a GET request message has no defined semantics; 
sending a payload body on a GET request might cause some existing 
implementations to reject the request." -- 
<http://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.3.1.p.4>

Defining semantics for GET bodies *is* a change to RFC 7231.

> ...

Best regards, Julian

Received on Wednesday, 29 April 2015 13:54:16 UTC