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

On 29/07/2016 4:20 a.m., Graham Leggett wrote:
> On 27 Jul 2016, at 7:13 PM, Roy T. Fielding wrote:
> 
>>> Could an RFC7234 compliant cache use a request body as part of the cache key, if it was so defined for a particular method?
>>
>> Yes.
>>
>>> Concrete example: If a cache cached a PROPFIND request keyed against a request body and URL, would that be RFC7234 compliant? Same for a SEARCH request?
>>
>> Yes (assuming the PROPFIND response is marked cacheable) and Yes (ditto).
>> The problem is ensuring that the body is sufficiently limited so that it
>> won't be unique per request.
>>
>> Caches that do not support this kind of caching should simply pass the
>> request/response through unharmed. Actual mileage may vary.
> 
> What would be a reasonable way to configure a RFC7234 compliant cache that wants to cache methods other than GET?
> 
> Would it be reasonable to explicitly specify the methods the cache is willing to cache, and have “GET” as the default? for example:

Not easily. Each method has its own requirements or prohibitions about
caching. That includes a prohibition against caching unknown methods.

The criteria for most methods is quite complicated at times, so no
simple cache method X will be sufficient unless the proxy is coded to
know what to check for when caching method X. In which case you may as
well cache that method by defaut as well, and allow non-caching to be
the configurable aspect.

That is how we do it in Squid. Caching everything we can by default.
Just providing various ways for admin to limit what gets stored, or
manipulate the heuristic algorithms for revalidating things already stored.

Amos

Received on Friday, 29 July 2016 07:31:13 UTC