httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: svn commit: r1070179 - in /httpd/httpd/trunk: CHANGES docs/manual/mod/mod_cache.xml modules/cache/cache_storage.c modules/cache/cache_storage.h modules/cache/mod_cache.c modules/cache/mod_cache.h
Date Mon, 14 Feb 2011 08:27:57 GMT
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
Mime
View raw message