Re: NEW ISSUE: Methods and Caching

Let me try to rephrase it to see if I understood:

A 200 response to *any* method (given headers like Content-* don't
indicate otherwise), can be returned on a subsequent GET/HEAD by
a cache (ignoring validation handling for now).

So, the cache is caching resource representations, not responses to
specific request types. There is no cached response for a POST, separate
to a cached response to a GET and to a PATCH and so forth. Instead the
cache is holding at most *one* entry per URI.

Unsafe methods like POST clear the cache for the request URI, before any
processing is done. Which enforces a cache miss and a forwarding of the
request to the server (or up the cache chain).

Would that describe the principal operation of a HTTP cache (ignoring
all the fine details of cache-control and so forth)?

//Stefan

> 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 Thursday, 20 November 2008 09:18:03 UTC