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

On 07/28/2016 12:32 AM, Willy Tarreau wrote:
> On Thu, Jul 28, 2016 at 01:25:00AM +0000, Adrien de Croy wrote:
>> Is GET with Content-Length: 0 semantically different to GET with no
>> Content-Length header since the body has no defined semantics in http?
> 
> Normally it is the same except that it indicates that the sender considers
> there's an empty body instead of no body

In other words, it may be semantically different [for the sender and
possibly the ultimate recipient of the message].


>> Is it therefore appropriate to strip Content-Length: 0 from GET requests?

> I don't see why it would not be. 

Your own [correct] explanation above shows why it would not be.
Stripping Content-Length:0 from GET requests may strip vital sender's
information.

Was it a good idea for the sender to use Content-Length:0 to carry vital
information? Of course not! However, from protocol point of view, "let's
strip Content-Length: 0 from GET requests" is equivalent to "let's
violate HTTP [payload forwarding requirements]".

If we acknowledge that empty payload may be semantically significant for
the sender, we should not encourage its removal.


>    A user agent SHOULD NOT send a
>    Content-Length header field when the request message does not contain
>    a payload body and the method semantics do not anticipate such a
>    body.

So, if a received request message has an [empty] payload body, we ought
to assume that the presumably compliant user agent meant to send it!
Note that the above requirement does not say "non-empty payload". In
other words, it tells user agents to avoid Content-Length [in GETs and
such] unless they do want to send [any] payload.


Cheers,

Alex.

Received on Thursday, 28 July 2016 16:40:32 UTC