Re: can GET do for QUERY? extending Partial Content


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


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

Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Wednesday, 29 April 2015 12:46:34 UTC