Re: NEW ISSUE: Methods and Caching

On Nov 18, 2008, at 2:50 PM, Brian Smith wrote:

> Roy T. Fielding wrote:
>> The fact that your experience would lead you to believe that GET  
>> is the
>> only method worth caching is irrelevant.  It is a design choice based
>> on the fact that HTTP is not a storage interface and cannot be  
>> presumed
>> to act like one.  The only reason this is confusing in 2616 is  
>> because
>> the section on caching does not reflect the WG opinions on how HTTP
>> caching works.  Rather than simply state the content of the cache  
>> key,
>> the description goes around in circles.  HTTP caching is far simpler
>> when defined as a response cache.
>
> 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.  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.

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

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

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

....Roy

Received on Wednesday, 19 November 2008 20:58:43 UTC