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

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.

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

"Responses to POST requests are only cacheable when they include 
explicit freshness information (see Section 4.2.1 of [RFC7234]). 
However, POST caching is not widely implemented.

For cases where an origin server wishes the client to be able to cache 
the result of a POST in a way that can be reused by a later GET, the 
origin server MAY send a 200 (OK) response containing the result and a 
Content-Location header field that has the same value as the POST's 
effective request URI (Section 3.1.4.2)." -
<https://greenbytes.de/tech/webdav/rfc7231.html#rfc.section.4.3.3.p.4>, 
paragraph break added by me.

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.

Best regards, Julian

Received on Thursday, 28 July 2016 07:01:22 UTC