RE: NEW ISSUE: Methods and Caching

Roy T. Fielding wrote:
> On Nov 18, 2008, at 2:50 PM, Brian Smith wrote:
> > Then how does caching work for POST?
> 
> 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.

Let me make sure I understand your response:

(1) When a cache receives a POST request, it MUST always forward to the
origin server, even if it already has a previous matching response in its
cache. It MUST NOT return a cached response for any POST request. This is
stated in section 13.11.

(2) A POST response MAY be cached only if: (a) has appropriate Cache-Control
or Expires fields, AND (b) it has a Content-Location header that resolves to
the Request URI. All other POST responses MUST NOT be cached. The
Cache-Control/Expires requirement is in section 9.5. 

(3) When a cache receives a GET (or HEAD) request, it MAY return a
previously cached POST response that was a cached using the criteria in (2)
above, or it MAY return a previously cached GET (or HEAD) response. This
isn't stated anywhere in RFC 2616.

Is my understanding correct?

Can (2) and (3) be generalized: Any response to any method can be cached and
returned in subsequent GET and HEAD requests, as long as the response
includes Expires/Cache-Control and a Content-Location that resolves to the
Request URI? For example, a PROPFIND response that meets those conditions
could be returned for subsequent GET and HEAD responses on the request URI. 

What about the case where the method is not GET, HEAD, or POST, the
Content-Location isn't the same as the request URI, or Content-Location is
missing)? For example, can we cache PROPFIND or SEARCH responses and return
them for subsequent PROPFIND and SEARCH requests? What are the requirements
for caching extension methods--the method MUST be "safe" and the response
MUST include a Cache-Control/Expires header? Any other requirements?

> > Why isn't OPTIONS cacheable?
> 
> For the same reason that it is specified not to contain a body.
> It was a disagreement among the previous editors.

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

The non-cacheability of PUT and DELETE is stated the same way as the
non-cacheability of OPTIONS: "Responses to this method are not cacheable."
Granted, it isn't using MUST NOT language, but the statement is pretty clear
in forbidding the caching of any of those methods (AFAICT, for no good
reason).

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

It would be smart to at least warn cache implementers about the problems of
caching anything other than GET and HEAD, and to warn origin server
implementers to be (more) careful with their Cache-Control/Expires headers.

Regards,
Brian

Received on Thursday, 20 November 2008 00:14:38 UTC