Apparently (http://wiki.apache.org/cocoon/ControllingModCache), a POST request to a given URL should invalidate the cache. This does not seem to be the case with mod_disk_cache and Apache 2.2.6 (gentoo).
A POST request doesn't invalidate the cache, its just not cachable.
It is a BUG. You are correct POST request cannot be cached, but according to RFC2616 13.1: "Some HTTP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI, or by the Location or Content-Location headers (if present). These methods are: - PUT - DELETE - POST In order to prevent denial of service attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI."
The reason why I reported this is that it would make it *trivial* for users of Apache reverse proxied cache setups to invalidate items in their cache. Rather than relying on a low ttl for every document and linked pages being purged from the cache at different times, fixing Apache to meet the standards-mandated behaviour would give it quite an advantage: everything could have a high ttl and only those documents which were updated would need to be purged - and when the purge happened, it would be instant. Marvellous :) (Writing the code to fit it in with your cms would be a doddle too)
Can't you do the same purge with a GET ... Cache-control: max-age=0 (Not that this changes the status of this bug.)
Seems to yes - thanks for that :)
Created attachment 22459 [details] let PUT POST DELETE invalidate the cache Check for PUT|POST|DELETE and if we have a cache entry matching the request, remove that entry.
(In reply to comment #6) > Created an attachment (id=22459) [details] > let PUT POST DELETE invalidate the cache > > Check for PUT|POST|DELETE and if we have a cache entry matching the request, > remove that entry. > I think the patch misses some cases that will be caught by the patch I will add in a minute. 1. Even if cache_select returns DECLINED we can have a caches version of this resource. It is possible that this cached version looks stale at the *first* glance. A conditional request on the backend will show if this is true or not. So we must remove the cache entry regardless of the result of cache_select. 2. It is perfectly valid that a POST, DELETE or PUT request on a resource requires authorization whereas a GET request does not. So must avoid the shortcut that every request with an Authorization header present in the request gets declined.
Created attachment 22463 [details] Patch against trunk
Created attachment 22467 [details] move cache_remove_url to output filter Two parts to the patch, The first part is same as your logic, but I thought this was a little more clearer, and moves auth check before initialization of context. The second part (I am not sure this is right since it is not stated in RFC) is that we check if the PUT/POST/DELETE request was valid before removing the cache entry. The reason that if a method was disallowed in the current URL, then it is probably not nice to let it have any effect on the cache of that entity. Both parts are not really necessary, and your patch works fine, (I have verified it, and could find no fault with its logic) but I thought it might be nicer this way.
I filed bug 50774 for enhancements in cache invalidation. *** This bug has been marked as a duplicate of bug 15868 ***
Undo spam change *** This bug has been marked as a duplicate of bug 15868 ***