- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 29 Apr 2015 15:35:14 +0200
- To: Michael Sweet <msweet@apple.com>, henry.story@bblfish.net
- CC: Willy Tarreau <w@1wt.eu>, HTTP Working Group <ietf-http-wg@w3.org>
On 2015-04-29 14:46, Michael Sweet 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. For good reason, see the history in <http://tools.ietf.org/wg/httpbis/trac/ticket/19>. > I would expect overloading GET in this way to cause interop problems. Indeed. Best regards, Julian
Received on Wednesday, 29 April 2015 13:36:07 UTC