httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
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 <minfrin@sharp.fm> 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?
>
> 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.

Thoughts?

Thanks,

Paul

Mime
View raw message