Re: NEW ISSUE: Methods and Caching

On Nov 16, 2008, at 11:57 PM, Henrik Nordstrom wrote:

> On fre, 2008-11-14 at 19:11 -0800, 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?
>
> As already discussed extensively: no.

As designed, yes.  The http-caching discussion had the same problem -- a
small group went off and thought they could redesign HTTP caching on the
basis of their experience with file and CPU caches.  They were wrong.
When the discussion came up about HTTP having an entity-storage cache or
a response cache, the result was always that the method was part of the
cache key (a response cache).  It had to be because HTTP is intended to
usable as a generic interface protocol for non-Web information systems
that may have their own sets of methods.

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.

>> 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).
>
> Yes.
>
>> 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.
>
> Indeed.
>
> My proposal is to make the URI-only GET/HEAD cache model more  
> explicit,
> so future protocol additions hopefully do not fall into the same  
> trap of
> inventing new GET-type methods like WebDAV did..

No.  Those WebDAV discussions had nothing to do with caching or, for
that matter, reasonable design.  They are new methods for the sole
purpose of removing a single round-trip when interacting with a new
resource, which was proven back then to be a false design assumption
and defined anyway because of sheer pig-headed MS.

There is no danger of per-method caching suddenly causing people
to prefer other methods over GET.  Links are valuable because of the
identifier, not because people have to do GET on the identifier, and
the deployment problem alone is more than sufficient to encourage
people to use GET for retrieval when the URI is the target.
PROPFIND is stupid because it hides the identifier (and thus all
the other methods that might be applied on an identifier have to
be duplicated, not just GET).


....Roy

Received on Tuesday, 18 November 2008 21:02:05 UTC