Summary: | Provide Cache Purge operation | ||
---|---|---|---|
Product: | Apache httpd-2 | Reporter: | Felix Meschberger <fmeschbe> |
Component: | mod_cache | Assignee: | Apache HTTPD Bugs Mailing List <bugs> |
Status: | RESOLVED LATER | ||
Severity: | enhancement | CC: | chip, dave, ogi |
Priority: | P3 | Keywords: | MassUpdate, PatchAvailable |
Version: | 2.0.48 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | Patch to provide cache purge method (incl. mod_cache docu) |
Description
Felix Meschberger
2003-12-04 14:10:29 UTC
Attaching patch to existing implementation of the mod_cache and supporting files. Created attachment 9392 [details]
Patch to provide cache purge method (incl. mod_cache docu)
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. 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)? 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 ? 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? 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 :/ 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] Adding myself to the CC, I plan to look on adding PURGE to mod_cache in 2.1/trunk. 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. 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. 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. I didn't know about this bug and filed Bug 50774 for cache invalidation abilities but using content handlers instead. 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. |