On Feb 13, 2011, at 5:03 AM, Graham Leggett wrote: > On 13 Feb 2011, at 9:59 AM, Roy T. Fielding wrote: > >>> URL: http://svn.apache.org/viewvc?rev=1070179&view=rev >>> Log: >>> mod_cache: When a request other than GET or HEAD arrives, we must >>> invalidate existing cache entities as per RFC2616 13.10. PR 15868. >> >> Cache entries should not be invalidated unless the response comes >> back as a success (2xx). Likewise, it only applies to methods with >> known write effects (not including TRACE, OPTIONS, PROPFIND, etc.). >> >> This has already been updated in httpbis p6. > > Hmmm... > > So is it right to say that POST, PUT and DELETE should invalidate, while all > others would be left alone? > > Or do we need some kind of mechanism for modules that respond to new methods > to declare those methods as needing to be invalidated or not?
Well, I thought I could answer that with a simple link to the drafts, but they just got changed in the wrong direction. It should be implemented as invalidating when the response is 2xx and the method is *not* one of the safe ones (GET, HEAD, OPTIONS, TRACE, PROPFIND, and maybe REPORT). That way, a new extension method would invalidate on success. > Should the cache try and cache any of the other methods, or is cacheability > limited to GET only? It can cache other methods if it knows how to. PROPFIND is probably the only other method worth caching, but its key depends on a bunch of webdav stuff outside the URI. ....Roy
