httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Sherlock <>
Subject Re: mod_cache sends 200 code instead of 304
Date Thu, 10 Sep 2009 15:25:03 GMT
Graham Leggett wrote:
> Nicholas Sherlock wrote:
>> But couldn't it just send a 304 Not Modified code instead? At the moment
>> it ends up wasting large amounts of bandwidth on my website in the case
>> where you press refresh on an unmodified object in Firefox, which sends
>> these request headers:
> I kept this back to investigate as I have been ENOTIME, but I've noticed
> a small detail:

Actually, this problem was traced to a bug in PHP's Apache filter. It 
sets "no_local_copy" to 1 in its response to Apache, which denies 
mod_cache from creating its own 304 Not Modified response code.

> Etags and If-None-Match are HTTP/1.1 caching concepts, and yet you're
> sending a response back to the cache telling the cache that you are an
> HTTP/1.0 server.
> I suspect what is happening is that the cache is seeing an HTTP/1.0
> response with HTTP/1.1 headers in it, and is in turn ignoring your 304
> not modified response.
> Try change your response to 'HTTP/1.1 304 Not Modified' instead.

I think I changed it to HTTP/1.0 as a last resort after I had exhausted 
all my other options. I changed it back to HTTP/1.1, and no change, it 
still gives the same behaviour.

> Another thing to check, you're using a function called "header" to set
> what is really the response status line, I'm not a php person, but that
> looks wrong to me.

header() is correct for setting response headers in PHP :).

> Check you aren't sending back a 200 OK without realising it (which will
> cause the cache to go "oh, the entity just got refreshed, send 200 back
> to the original client", which is in turn the symptom you are seeing).

The PHP script is definitely sending a 304, it logs it to a file to 
confirm (and I've verified that file). You can actually tell that 
mod_cache is getting the 304 response code, because mod_cache serves the 
document body from the cache along with the incorrect 200 code (the body 
of the 304 response from PHP itself is of course empty). Using that test 
code, if the branch that was supposed to set a 304 code set a 200 code 
instead, you would expect an empty document body.

I'm currently running unmodified Apache and PHP patched to not set 
no_local_copy=1 in its response constructor on my production server, and 
mod_cache works flawlessly - the 304 code is correctly sent to the 
client instead of the 200 code.

Nicholas Sherlock

View raw message