Re: NEW ISSUE: Methods and Caching

I'd also propose clearing up nomenclature relating to "cachability".  
The same word used is used for 2 completely different meanings, being

a) response permitted to be stored into a cache
b) request permitted to be responded to by a cache

GET/HEAD responses can be stored in and GET/HEAD requests can be 
responded to by a cache.  POST responses can be stored into a cache, but 
POST requests cannot be responded to by a cache.

I think the misuse of the word "cacheable" is causing additional confusion.

Mark Nottingham wrote:
> [ trimming the CC: list ]
> Well, we need to look at how all of the requirements are specified, 
> and how they fit together. Currently, this entire area is very fuzzy, 
> especially reqarding extension methods, so we need to sort it out.
> As I said before, I think this could go either way, but personally I'm 
> leaning towards NOT putting the method in the key cache key, for two 
> reasons;
> 1) Major shared cache implementers interpret it this way (see Henrik's 
> mail, for example).
> 2) Allowing non-GET methods to be cacheable will IMO encourage the 
> development of GET-like extension methods. This will result in a lot 
> of data and metadata that isn't "on the Web" (i.e., you can't just 
> dereference a link to obtain it; now you need to know the correct 
> method as well).
> #1 may be a stronger reason to go this way as per our charter, but I 
> think in the long run #2 is a stronger motivation.
> On 18/11/2008, at 10:03 AM, Julian Reschke wrote:
>> Henrik Nordstrom wrote:
>>> ...
>>> Extension methods MAY define their own cache rules, but only applies to
>>> caches implementing the same. PROPFIND has already been mentioned in
>>> this discussion and as a note can be mentioned that a cache which only
>>> implements the base HTTP/1.1 specifications will invalidate any cached
>>> objects on the URI when seeing a PROPFIND request for that URI.
>>> ...
>> The method registry we're building 
>> (<>) 
>> will tell implementers that PROPFIND is safe -- that should be 
>> sufficient for not requiring invalidate, right?
>> BR, Julian
> -- 
> Mark Nottingham

Adrien de Croy - WinGate Proxy Server -

Received on Wednesday, 19 November 2008 06:58:18 UTC