httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dan Poirier <>
Subject Re: HTTP Protocol: How frequently should browser repeat requests after 304 responses?
Date Wed, 17 Sep 2008 23:46:26 GMT
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 

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


View raw message