On Sun, Feb 13, 2011 at 5:03 AM, Graham Leggett <[email protected]> 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
