- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 18 Nov 2008 23:02:21 -0800
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
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 UTC