[EMAIL PROTECTED] wrote:
[...]
I found out that during the second request which returns a 304 the CACHE_SAVE filter, which would be able to deal with such things (-> (not so) stale cache entries) is never used. The change of the conditionals in cache_storage.c starting at line 269 leads to the creation of a 304 code in the default handler and the default handler does not pass 304 responses down the filter chain.
Then that is a bug. We've seen the same problem in mod_proxy.
So the 304 response is delivered instead of the (not so) stale cache entry. So I created the following patch to cache_storage.c which prevents the modification or better creation of any conditionals if the original request did not contain any:
No, this is what we were trying to prevent.
I am aware that this forces a full request to the backend for requests without conditionals to expired resources. So I am not very happy with this solution. Maybe it is better to let the default handler pass 304 responses down the filter chain.
Might as well not do revalidation in that case; actually that would be better, because the 304's that are returned may not even be correct. The conditions are replaced with the ones from the cache, remember?
Some might also say that my configuration seems stupid (do disk caching for static resources, which was actually born during some tests for another problem I am currently hunting), but this problem also applies to other providers than mod_disk_cache and the document root might be on a non local disk.
I can see the application. Are you up for submitting a patch to the default handler? :) Sander
