httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <>
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 Sun, 13 Feb 2011 23:56:52 GMT
On Sun, Feb 13, 2011 at 5:03 AM, Graham Leggett <> wrote:
> On 13 Feb 2011, at 9:59 AM, Roy T. Fielding wrote:
>>> URL:
>>> 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?
> Should the cache try and cache any of the other methods, or is cacheability
> limited to GET only?

Additionally, this should be a configurable behavior.

Lets say you run a popular website that depends on mod_cache to
protect backend systems from complete overload.

All you need to do now as an attacker is POST / DELETE to / or another
important URL every 200ms, and the cache becomes invalidated, causing
a flood of requests to backends that might not be able to support it.




View raw message