httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sander Striker <stri...@apache.org>
Subject Re: mod_cache deliver 304 instead of (not so) stale cache entries
Date Sat, 21 May 2005 23:42:04 GMT
> r.pluem@t-online.de 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

Mime
View raw message