httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <>
Subject Re: mod_cache sends 200 code instead of 304
Date Wed, 09 Sep 2009 17:01:00 GMT
Nicholas Sherlock wrote:

> If you make a conditional request for a cached document, but the
> document is expired in the cache, mod_cache currently passes on the
> conditional request to the backend. If the backend responds with a "304
> Not Modified" response that indicates that the cached copy is still up
> to date, mod_cache serves the contents of the cache to the client with a
> 200 code.
> 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:

> if (isset($_SERVER['HTTP_IF_NONE_MATCH']) &&
>     $_SERVER['HTTP_IF_NONE_MATCH'] == $etag) {
>     /* At a users' request, the cache has been bypassed, but the
>      * document is still the same. Avoid costly response generation
>      * and waste of bandwidth by just sending not-modified.
>      */
>     header('HTTP/1.0 304 Not Modified');
>     error_log(date('r')." - Response: 304 Not Modified\n");
>     exit(); //Don't generate or send the body
> }   

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.

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.

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).


View raw message