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.
Cheers,
Nicholas Sherlock
