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

bodies on GET is a can of worms.

how can GET be idempotent if we allow bodies on GET and say they have no 
defined semantics within HTTP?

Is GET with Content-Length: 0 semantically different to GET with no 
Content-Length header since the body has no defined semantics in http?

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

Seems like the potential for request smuggling is large with bodies on 
GET.

Shouldn't we just ban them?  I'm sure this has been discussed at length 
on here many times before.

Maybe at least be a little stronger in the language?

e.g. clients SHOULD not send bodies on GET.

Adrien


------ Original Message ------
From: "Adrien de Croy" <adrien@qbik.com>
To: "Alex Rousskov" <rousskov@measurement-factory.com>; 
"ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Cc: "Julian Reschke" <julian.reschke@greenbytes.de>
Sent: 28/07/2016 1:00:15 PM
Subject: Re: RFC7234: Can a request body form part of a "cache key"?

>
>
>------ Original Message ------
>From: "Alex Rousskov" <rousskov@measurement-factory.com>
>To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
>Cc: "Julian Reschke" <julian.reschke@greenbytes.de>; "Adrien de Croy" 
><adrien@qbik.com>
>Sent: 28/07/2016 11:26:39 AM
>Subject: Re: RFC7234: Can a request body form part of a "cache key"?
>
>>On 07/27/2016 03:37 PM, Julian Reschke wrote:
>>>  On 2016-07-27 22:56, Adrien de Croy wrote:
>>>>  maybe need something like
>>>>
>>>>  Vary: Request-Body
>>
>>
>>>  I'd say this is implied anyway.
>>
>>
>>RFC 7231 appears to imply the opposite: It explicitly allows GET
>>requests with bodies
>
>"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."
>
>Same for HEAD.
>Does anyone allow bodies on GET?  We block them I think.
>
>I've also seen bodies on CONNECT...
>
>Adrien
>
>
>
>>while not placing any request-body-related
>>restrictions on their response cachability and sharing AFAICT.
>>Similarly, there are instructions for caching POST responses that do 
>>not
>>mention request body importance (and nearly implying its irrelevance 
>>by
>>mentioning GET hits for POST-cached responses).
>>
>>Alex.
>>
>
>

Received on Thursday, 28 July 2016 01:25:35 UTC