W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

Re: NEW ISSUE: Methods and Caching

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 18 Nov 2008 10:40:53 -0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <E0BD8480-BAE5-4C73-A392-040B022ABE54@mnot.net>
To: Julian Reschke <julian.reschke@gmx.de>

[ 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  

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 (<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-method-registrations-00.html 
> >) will tell implementers that PROPFIND is safe -- that should be  
> sufficient for not requiring invalidate, right?
> BR, Julian

Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 18 November 2008 18:41:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:47 UTC