Re: RFC7234: Can a request body form part of a "cache key"?

the text in the RFC is

"A payload within a GET request message has no defined semantics;"

I guess it comes down to interpretation as to whether you take that to 
mean

a) this document defines no semantics for the body on GET request 
messages
b) this document prohibits any semantic meaning being applied to the 
body on GET request messages

If you take the former interpretation then we have this situation.

If you take the latter, then I think it should be re-worded to be more 
specific, since it has implications like a proxy being free to strip 
bodies off GET request messages etc.

Adrien


------ Original Message ------
From: "Roy T. Fielding" <fielding@gbiv.com>
To: "Alex Rousskov" <rousskov@measurement-factory.com>
Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>; "Julian Reschke" 
<julian.reschke@gmx.de>; "Adrien de Croy" <adrien@qbik.com>
Sent: 29/07/2016 5:55:56 AM
Subject: Re: RFC7234: Can a request body form part of a "cache key"?

>>  On Jul 28, 2016, at 9:07 AM, Alex Rousskov 
>><rousskov@measurement-factory.com> wrote:
>>
>>  On 07/28/2016 01:00 AM, Julian Reschke wrote:
>>>  On 2016-07-28 01:26, Alex Rousskov wrote:
>>>>  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 while not placing any request-body-related
>>>>  restrictions on their response cachability and sharing AFAICT.
>>
>>>  I don't see how this means that you could ignore the body should you
>>>  decide to cache it.
>>
>>  What is not prohibited is allowed. If caching a GET response while
>>  paying no attention to the GET request body is not prohibited, then 
>>it
>>  is allowed. If it is allowed, then "Vary: Request-Body" is not 
>>implied
>>  in the GET transaction context.
>
>I don't know how you came up with that twisted logic. GET is defined
>as having no semantics for any body if it is present.  As such, an
>implementation would be broken to do anything other than to parse and
>discard that body if received.  Actually using the body to affect the
>request would imply it has semantics.
>
>There is no such thing as "Vary: Request-Body".  That isn't a field 
>name,
>would not be useful in Vary, and would have no effect on caching (other
>than disabling it for caches that panic on vary).
>
>>>>  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).
>>
>>
>>>  So these are two distinct things; the POST itself could be cacheable
>>>  *and* the POST response can be decorated to imply that it can be 
>>>used
>>>  for subsequent GET requests.
>>
>>  I am talking about the latter. The explicit and detailed instructions 
>>on
>>  how to make a POST response cachable do not say anything about 
>>variance
>>  on the POST request body. Thus, "Vary: Request-Body" is not implied 
>>in a
>>  POST transaction context.
>>
>>  We can all join in a happy hand-waving exercise while talking about
>>  "intent", "practice", and blocking valid messages we dislike, but 
>>until
>>  somebody finds a _protocol_ requirement that clearly implies "Vary:
>>  Request-Body", there is no such implication.
>
>Feel free to implement it either way.  The semantics for POST are quite
>loose, so the notion that there will be any independent 
>interoperability
>here is quite fanciful.  However, there is still an opportunity for 
>specific
>services where knowledge about what that POST means is known to the 
>cache.
>
>The same applies to PROPFIND and SEARCH, but those methods are defined 
>by
>other specs that are free to define semantics for the body.
>
>....Roy
>

Received on Thursday, 28 July 2016 21:34:13 UTC