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

Re: NEW ISSUE: Methods and Caching

From: Adrien de Croy <adrien@qbik.com>
Date: Wed, 19 Nov 2008 20:00:02 +1300
Message-ID: <4923B972.6060405@qbik.com>
To: Mark Nottingham <mnot@mnot.net>
CC: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>


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 
>> (<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/
>
>

-- 
Adrien de Croy - WinGate Proxy Server - http://www.wingate.com
Received on Wednesday, 19 November 2008 06:58:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:57 GMT