- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 18 Nov 2008 10:40:53 -0800
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
[ 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/
Received on Tuesday, 18 November 2008 18:41:31 UTC