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

On 07/28/2016 11:55 AM, Roy T. Fielding wrote:
>> 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. 

Sorry, but I see nothing twisted about it. It feels very
straightforward, actually, but I am obviously biased.


> GET is defined
> as having no semantics for any body if it is present.

HTTP RFCs do not define GET body semantics. That does not mean an
implementation may not assign its own semantics to that body. Naturally,
such an implementation would still have to rely on standard HTTP
mechanisms to correctly deliver that body to an origin server [which
understands that custom semantics].


> As such, an
> implementation would be broken to do anything other than to parse and
> discard that body if received.

A specific origin server implementation that recognizes the body (based
on the URI, headers, or otherwise) may interpret it according to that
body semantics. A proxy implementation should forward that body intact
[unless the proxy is deployed to police/sanitize traffic]. If HTTP wants
to require some other/specific behavior, it should say so explicitly. It
had an opportunity to do that, but did not. It only said that some
servers _might_ reject GETs with bodies.


> Actually using the body to affect the request would imply it has semantics.

Agreed.


> 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).

Yes, and I hope everybody on this thread knows that it is just a
convenient notation to say "this [cachable] response variant depends on
the request body as a whole".


>> 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.

Agreed! Your suggestion matches my assertion that there is no
protocol-level "Vary: Request-Body" implication in this area. Caching
implementations need to proceed with great caution, but they cannot be
called non-compliant if they do not assume "Vary: Request-Body".


> The same applies to PROPFIND and SEARCH, but those methods are defined by
> other specs that are free to define semantics for the body.

... but regardless of how they define that semantics, if they want that
request body to affect cachability of the response, they have to use
standard HTTP mechanisms to do so. For example, if they want the "Vary:
Request-Body"-like semantics, they could require a combination of
Content-Checksum request header and a "Vary: Content-Checksum" response
header.

Alex.

Received on Thursday, 28 July 2016 18:38:09 UTC