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 23:02:21 -0800
Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <D5423785-07DD-40AF-B53F-7AB402BB030E@mnot.net>
To: Adrien de Croy <adrien@qbik.com>

Yes, I'm working on a proposal for this now; stay tuned.

Cheers,


On 18/11/2008, at 11:00 PM, Adrien de Croy wrote:

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


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 19 November 2008 07:03:01 GMT

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