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 17:56:23 UTC