Re: NEW ISSUE: Methods and Caching

On ons, 2008-11-19 at 12:58 -0800, Roy T. Fielding wrote:

> The same way it has been defined in HTTP/1.1 since my first proposal.
> If the response is cacheable under the same URI, then it will be a 200
> response with a Content-Location that says it is the same as the
> request URI.  If it is cacheable under a different URI, then 303 is
> the preferred response in order to fill all caches in the chain
> without bypassing authority checks.

Where is the Content-Location requirement? Can't seem to find such
requirement, only a general recommendation to always send a
Content-Location, and cache rules on invalidation when there is a
Content-Location.

The cache note in POST says

   Responses to this method are not cacheable, unless the response
   includes appropriate Cache-Control or Expires header fields. However,
   the 303 (See Other) response can be used to direct the user agent to
   retrieve a cacheable resource.

And there from what I can tell is no requirement anywhere that cacheable
responses MUST have a Content-Location. But yes, there is a requirement
that servers SHOULD provide a Content-Location on any response where
there is a matching unique resource-URI, but at the same time it's a
little ambiguent by having a overlapping MAY requirement which kind of
indicates Content-Location is not needed if it's the same as the
requested URI.

> > Why aren't
> > PUT and DELETE cacheable the same way as POST?
> 
> They are if you read the individual response codes and field  
> definitions.

Can you elaborate?

> > I would like to see per-method caching but is it something that  
> > will really
> > get deployed? AFAIK no implementations are doing it. Plus, I bet  
> > lots of
> > servers attach Cache-Control headers to POST responses accidentally.
> > Apache's mod_expires will add Cache-Control/Expires headers for  
> > every method
> > for all request URIs where it is active, so undoubtedly lots of Apache
> > instances are returning POST responses with Cache-Control even  
> > though they
> > don't want the response to be cached.
> 
> That is not a problem.

How so?

When is a server unintentionally stating that a temporary status
response is cacheable not a problem?

Unless you mean it's not a problem in or due to the specifications, just
a broken server.

> > Based on the current state of implementations, it is better to  
> > restrict
> > caching to GET/HEAD for now and add cacheability for other methods  
> > in a
> > future version of the protocol.
> 
> No.  The right thing to do is to remove the artificial restrictions
> that were made in the absence of any implementations and let the
> messages be self-descriptive.

Agreed.

Regards
Henrik