httpd-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [users@httpd] Force IE to cache
Date Thu, 02 Oct 2008 20:24:30 GMT
howard chen wrote:
> Hello,
> In the httpd.conf, I have already set all the images files to expire
> +10 years from now, using mod_expire.
> Example response:
> =============
> Status=OK - 200
> Date=Thu, 02 Oct 2008 16:23:15 GMT
> Server=Apache
> Last-Modified=Thu, 27 Mar 2008 08:02:14 GMT
> Accept-Ranges=bytes
> Content-Length=3945
> Cache-Control=max-age=315360000
> Expires=Sun, 30 Sep 2018 16:23:15 GMT
> Keep-Alive=timeout=5, max=100
> Connection=Keep-Alive
> Content-Type=image/gif
> I use Firefox to verify the expiry date, using about:cache, also tell
> me the correct value.
> Something quite strange, in the access log, there are quite a many of
> 304 Not Modified response. Since I have manually set an expire to 10
> years, so the client should NOT request again  and again (yes, they
> might hit F5, but I don't think there are so many people do the F5
> every day .... 50% of all request).
> After checking the log, I found most the 304 response is for client
> IE6/IE7. Any things I have missed?

Very respectfully and tentatively, I would submit the following :

1) long experience with the WWW tells me that you cannot "force" a web 
client to do anything.  The server can suggest, and the HTTP RFCs 
dictate some behaviours that the client *should* follow, but basically 
from the server point of view, you cannot trust that the client will do 
That is also not too bad, because can you imagine for a minute that a 
HTTP server *could* force your browser to do something that you do not 
want ?  There are good and bad clients, but there are also good and bad 

2) I have not verified, but maybe you are interpreting the rules of 
caching a bit more extensively than what the HTTP RFCs really say.
It may be that, by using your various HTTP headers, your server is doing 
what it can to "suggest" to the browser that it should cache this object 
and not ask again for 10 years.  But maybe also, the RFC says that the 
client is not "forced" to respect this, and "can" ask again if the 
content has been replaced in the meantime or not.
After all, you are seeing 304 responses from the server.  This means 
that the browser has requested an object, but told the server "only if 
not modified since..", and the 304 of the server is "No, it has not been 
modified since then, you do not need to reload it". And consequently the 
browser uses its cached version, and it does not insist. (I suppose, 
because otherwise you would see another request from the browser, and 
another 200 OK response from the server).
That sounds to me like a rather acceptable behaviour.
After all, if you personally requested a page from a webserver, and the 
webserver told you "here it is, and it will not change in the next 10 
years", would you believe that ? and would you not check again before 
the 10 years have passed ?

3) If it was so that this behaviour is really against the spirit or the 
letter of the RFC, then I believe that the right people to discuss this 
with would be Microsoft. There is no guarantee that they will do 
anyhting about it however, judging by some other areas in which IE 
browsers have been in flagrant violation of the HTTP RFCs before.

I, and probably several tens of thousands of web developers with me, 
have been fighting the inconsistent behaviour of browsers for years, and 
spent many unproductive hours just trying to find hacks to get around 
these inconsistencies and insure a pleasant experience for users.  It 
gets better over time, but it is still not perfect.

What I am saying is, you may already have done what you could do, and 
maybe there is no additional thing you can do.  If the only inconvenient 
is an additional browser request, and a "light" 304 response from the 
server, that is not too bad.  At least the server does not have to 
re-send the content.

The official User-To-User support forum of the Apache HTTP Server Project.
See <URL:> for more info.
To unsubscribe, e-mail:
   "   from the digest:
For additional commands, e-mail:

View raw message