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. Regards Rüdiger
