Ruediger Pluem wrote:
On 09/17/2008 10:00 PM, Dan Poirier wrote:
I've looked at mod_expires doc and RFC 2616, but can't really
tell what the right behavior is supposed to be in this case.
Using mod_expire to set the expiration time to something like
"access plus 1 hour", we see a browser request a file, get back
a 200 with the expiration, and not request it again for an hour,
as expected. The next time, it uses an if-modified-since and
gets back a 304, also good. But from then on, it keeps coming
back to the server every time and getting back 304's.
The 304 responses won't have any cache control information, of
course, per RFC 2616 10.3.5.
I don't read from RFC 2616 10.3.5 that there shouldn't be any cache
control
related headers contained in the response. On the contrary: If the values
for Expires or Cache-Control changed these values MUST be included.
So I guess we have a bug in mod_expires here. I guess this is caused by
the position of the MOD_EXPIRES filter in the filter chain. It is
AP_FTYPE_CONTENT_SET-2 as it needs to run before the cache save filter.
I guess (haven't checked so far) that we do not run through these filters
if a handler simply returns a 304.
Looking at a wire trace, we are actually providing Expires and Cache-control
on the 304 response. So whatever the browser is doing, that's not the
cause.
If I keep hitting reload in Firefox, I do see requests more frequently
than the
max-age - but maybe Firefox reasons that my hitting reload on the same page
means I really do want to go back to the server despite the caching. Which
might mean the whole test is invalid. I'm going to need to investigate some
more.
Dan
