Re: NEW ISSUE: Methods and Caching

I think it is pretty clear, that the method is part of the cache key, 
otherwise a new completely unrelated method, which does always return 
the same response entity (and thus marked as cachable), will interfere 
with the next unrelated GET. That blocks new (and old) methods from 
defining sensible caching strategies.

Same people like to have a POST response cached for the next GET to 
come, but this effect can be achieved by better means:
Use a 303 "See Other". This 303 may get cached and the following GET, 
too.

This allows mixing "status-responses" and "entity-responses" on the 
discretion of the server, as HTTP does already.


Robert


On Sat, Nov 15, 2008 at 01:36:15PM -0800, Mark Nottingham wrote:
> 
> #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 Sunday, 16 November 2008 03:35:49 UTC