- From: Adrien de Croy <adrien@qbik.com>
- Date: Wed, 19 Nov 2008 20:00:02 +1300
- 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 UTC