Re: NEW ISSUE: Methods and Caching

#139; <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/139>.


On 14/11/2008, at 7:11 PM, Mark Nottingham wrote:

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


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

Received on Saturday, 15 November 2008 21:36:54 UTC