NEW ISSUE: Methods and Caching

RFC2616 does not clearly define what the relationship of the request  
method is to caching. In particular, does the method form part of the  
cache key?

If the method does not form part of the cache key, a cache can  
effectively only be used to satisfy GET and HEAD requests, but a non- 
GET/HEAD response could "populate" the cache if it had explicit expiry  
information; e.g., a POST response could be used to satisfy a future  
GET request (if the POST response were marked as explicitly cacheable).

If the method does form part of the cache key, any method (e.g.,  
OPTIONS, PROPFIND) could potentially be cached and returned in  
response to future requests.

Relevant text;

9.5 POST:
> Responses to this method are not cacheable, unless the response  
> includes appropriate Cache-Control or Expires header fields.

13.11 Write-Through Mandatory:
> All methods that might be expected to cause modifications to the  
> origin server's resources MUST be written through to the origin  
> server. This currently includes all methods except for GET and HEAD.  
> A cache MUST NOT reply to such a request from a client before having  
> transmitted the request to the inbound server, and having received a  
> corresponding response from the inbound server. This does not  
> prevent a proxy cache from sending a 100 (Continue) response before  
> the inbound server has sent its final reply.

IME current implementations do not cache any non-GET/HEAD responses,  
so either path is open.

Personally, my understanding has always been that methods do not form  
part of the cache key and this is also my preference; I'm concerned  
about the specification complexity making it part of the key would add  
(e.g., around variant selection, making the write-through requirement  
compatible with future cacheable methods), as well as getting  
implementation support and the likely proliferation of GET-copycat  
methods.


--
Mark Nottingham     http://www.mnot.net/

Received on Saturday, 15 November 2008 03:12:24 UTC