Re: Bodies on GET (again) - was Re: RFC7234: Can a request body form part of a "cache key"?

> On 28 Jul 2016, at 8:35 AM, Willy Tarreau <w@1wt.eu> wrote:
> 
> On Thu, Jul 28, 2016 at 08:32:54AM +0200, Willy Tarreau wrote:
>>> Maybe at least be a little stronger in the language?
>>> 
>>> e.g. clients SHOULD not send bodies on GET.
>> 
>> I tend to think that the way it is done right now ensures that nobody is
>> willing to make shortcuts in their parsers and that's important. However
>> what we could have done (I thought we had it but can't find it) would be
>> to mention that a server MAY reject a GET with a body. That's more
>> dissuasive for clients and that still indicates that the server is not
>> allowed to be lazy on this.
> 
> Just found it after sending, that's at the end of 4.3.1 in #7231 :
> 
>   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.
> 
> It's less strong than what I thought however, I think we could suggest
> servers to reject these requests if they don't intend to process the
> body (nor simply to parse it).

Pretty much.

The intent was to clarify that all requests can have bodies syntactically, because we have a (somewhat) generic message parsing model; HTTP software that doesn't care about the method (e.g., a proxy) shouldn't have to know about it to parse a message. 

However, GET itself defines no semantics, so it's useless to send one. That means that various software can and will assume that such a thing is useless if they *do* pay attention to the method, and may refuse it -- including things like firewalls, WAFs, etc.

Practically speaking, you're going to have a problem if you use a body on a GET with systems you don't own (i.e., at any scale). It may work as a pre-arranged, pairwise thing, but that's not really a primary use case for HTTP (and you're effectively creating a private GET by doing so).

Cheers,


--
Mark Nottingham   https://www.mnot.net/

Received on Thursday, 28 July 2016 13:30:08 UTC