- From: Michael Sweet <msweet@apple.com>
- Date: Wed, 29 Apr 2015 05:46:01 -0700
- To: henry.story@bblfish.net
- Cc: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
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. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 29 April 2015 12:46:34 UTC