Bug 25201 - Provide Cache Purge operation
Summary: Provide Cache Purge operation
Status: RESOLVED LATER
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_cache (show other bugs)
Version: 2.0.48
Hardware: All All
: P3 enhancement with 3 votes (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords: MassUpdate, PatchAvailable
Depends on:
Blocks:
 
Reported: 2003-12-04 14:10 UTC by Felix Meschberger
Modified: 2018-11-07 21:09 UTC (History)
3 users (show)



Attachments
Patch to provide cache purge method (incl. mod_cache docu) (17.55 KB, patch)
2003-12-04 14:13 UTC, Felix Meschberger
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Meschberger 2003-12-04 14:10:29 UTC
We place Apache httpd 2.0 in front of our CMS product as a caching reverse proxy
to enhance performance. While the cache properly works managing its cached
resources there is currently no functionality for the CMS product to inform the
proxy about changed content.

I propose to enhance the mod_cache module to support a new configuration
directive "CachePurgeMethod" with default "PURGE". When a request for such a
method comes in the mod_cache handles it by trying to remove the indicated cache
entry.

If the cache entry exists, the .data and .header file is removed and the request
is terminated with a OK/200 status. If no cache entry exists for the request
URL, the request is terminated with a NOT_FOUND/404 status.

This behaviour (method to purge a cache entry and the status codes for
(un)successfully removal) is sketched after the PURGE method support of the
squid cache. See http://www.squid-cache.org/Doc/FAQ/FAQ-7.html#ss7.5 for short
information.
Comment 1 Felix Meschberger 2003-12-04 14:12:08 UTC
Attaching patch to existing implementation of the mod_cache and supporting files.
Comment 2 Felix Meschberger 2003-12-04 14:13:21 UTC
Created attachment 9392 [details]
Patch to provide cache purge method (incl. mod_cache docu)
Comment 3 Felix Meschberger 2003-12-04 14:14:28 UTC
One final note: I could not get the 2.0 branch head to compile, therefore this
patch is made against the 2.0.48 tag. I hope nothing much has changed in this
arena since 2.0.48...

Sorry for this inconvenience.
Comment 4 André Malo 2003-12-04 14:38:29 UTC
The documentation example should contain a big warning with example, that access
to this method should be restricted. Otherwise it's nothing but a DoS vulnerability.

But I'm wondering how ... (wihtout affecting other methods or restrictions)?
Comment 5 Felix Meschberger 2003-12-13 17:11:52 UTC
i could image somthing like 
<CachePurgeMethod METHOD_NAME>
   # limit settings
</CachePurgeMethod>

which would be used like the <LIMIT> directive to limit the use of methods. this
would allow to restrict the use based on authentication and/or source address.
if the mod_cache decides to not accept the method based on configuration and
request, it would simply DECLINE and have the rest of the system act accordingly.

i completely agree, that there must be some mechanism to restrict use of this
method. but i have to admit, that i neglected this issue :-(

what do you think ?
Comment 6 Joshua Slive 2003-12-13 23:11:25 UTC
I don't understand.

Isn't PURGE an HTTP method just like GET or POST?  If so, should you just use
<Limit PURGE> (or <LimitExcept GET>) to do access control?
Comment 7 André Malo 2003-12-14 00:34:25 UTC
The problem is, that  <Limit> doesn't work accumulative. So, if one uses, say

<Directory />
  <Limit PURGE>
#   blah
  </Limit>
</Directory>

a single

<Limit POST>
</Limit>

Container later will override the PURGE limit. We need a better solution in
general. <Limit> should be deprecated in favour of something better :/
Comment 8 Felix Meschberger 2003-12-14 10:05:24 UTC
if <limit> itself can do what i want it to do :

 - define the name of the method mod_cache accepts to purge a cache entry
 - define restrictions on the use of this same method
 - being limited to mod_cache - that is having no influence on other modules or
   overall configuration and not being influenced from other modules or
   overall configuration

then limit is ok, don't you think ?

but ! if limit cannot do this or if limit may be overruled from outside the
mod_cache configuration, <limit> is not ok.

as - to my knowledge - there is no special container directive for mod_cache
other than <directory>, etc., i think there must be a special named directive,
which exactly does what i want it do (see list above).

maybe i just miss some point, in which case i gladely agree to whatever you propose.

btw: the intended idea of having a directive defining the name of the method to
use is, that mod_cache will handle the request and not give any other module a
chance to see the request in case mod_cache can handle it. and to my knowledge
there is no standard method named 'PURGE' [i only know that squid uses this
method exactly for this purpose]
Comment 9 Paul Querna 2005-04-17 23:06:27 UTC
Adding myself to the CC, I plan to look on adding PURGE to mod_cache in 2.1/trunk.
Comment 10 Graham Leggett 2010-09-27 17:29:15 UTC
From what I can see, I don't see what PURGE does that isn't already done by a GET with a "Cache-Control: no-cache" header (to refresh) or "no-store" header (to purge) in the request?

I suspect what is being attempted here is already offered out the box by RFC2616.
Comment 11 Felix Meschberger 2010-09-28 02:21:20 UTC
THe scope of the PURGE method is different from the GET method with cache-control headers.

The goal here is to provide functionality to the server behind the caching proxy to update the caching proxy: If the server sees a change, it will update the proxy
to flush the old contents from the cache.

Sending a GET request with cache control preventing caching should not cause the cached data to be purged from the cache.
Comment 12 Graham Leggett 2010-10-18 19:12:45 UTC
What you're talking about is a conditional request, which comes as standard in RFC2616.

Send a GET request with the header "Cache-Control: max-age=0". If the cache has a cached entity, it will add a conditional "If-None-Match" or "If-Modified-Since" header, to which your server responds with "304 Not Modified" if the content has not changed, or "200 OK" followed by the new content if the content has changed.

Any CMS should support conditional requests as a matter of course, as they represent a significant performance improvement.
Comment 13 Ognyan Kulev 2011-02-17 03:34:05 UTC
I didn't know about this bug and filed Bug 50774 for cache invalidation abilities but using content handlers instead.
Comment 14 William A. Rowe Jr. 2018-11-07 21:09:16 UTC
Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.