- From: Willy Tarreau <w@1wt.eu>
- Date: Wed, 29 Apr 2015 17:32:58 +0200
- To: Michael Sweet <msweet@apple.com>
- Cc: Eric Covener <covener@gmail.com>, henry.story@bblfish.net, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Apr 29, 2015 at 08:15:31AM -0700, Michael Sweet wrote: > GET is not defined as accepting a message body in the request, in either RFC > 2616 or RFC 7231. And in fact RFC 7231 has the following to say: > > 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. > > which supports what I have said so far: doing a GET with a request body is > probably not a good idea without some way for the server to indicate that > such semantics are supported by the server's GET implementation. ... and all the intermediaries, which is often where most of the problems will lie. I can tell you for sure that if you try to pass that through an old haproxy 1.3, only the headers will pass, the body will wait, and the server will wait for the data until haproxy declares a server timeout. Fortunately newer versions are much more standards-compliant, but such products are still found in field and even naive implementations of non-compliant intermediaries are found at many places. The purpose of RFC723x was to tell people what's known to be broken and what is safe. It doesn't mandate what people have to do, just what they should do to avoid shooting themselves in the foot. If there are people who prefer to try a few bullets before knowing if their feet are *that* sensible, we can't do anything more to warn them :-/ Regards, Willy
Received on Wednesday, 29 April 2015 15:33:27 UTC