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 it. 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 servers.
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:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|