Karl, The best way I've found to examine caching headers is the Live HTTP Headers firefox add on. This is what it says about your homepage: HTTP/1. X 200 OK Date: Fri, 06 Nov 2009 15:16:57 GMT Server: Apache Last-Modified: Mon, 12 Oct 2009 16:52:05 GMT Etag: "85dcc1-1386-4ad35eb5" Accept-Ranges: bytes Content-Length: 4998 Keep-Alive: timeout=10, max=99 Connection: Keep-Alive Content-Type: text/html As mentioned above, the etag is the issue.
A quick (unixy) fix might be: find /var/www/htdocs -type f|xargs touch which will change the modified time of every file in your www directory. It does, however, depend on how your apache instance is configured to generate the etag value. Here's a great little howto on setting up caching with Apache.As far as your suggestion to add a link, I don't think that will work.
You can't force a browser to refresh a page remotely, and, as pointed out above, the issue is with the etags, which your solution won't change. Dan.
Wait a while. Most users caches will expire in a period of hours, unless you set the server to serve the page with an unusually long cache hint. If you're serving the page now, you can set headers so that the client does not cache it.
See this question for that: stackoverflow.com/questions/1370896/what....
For example, the website I'm concerned with is mastercontrols.com. – Karl Nov 5 '09 at 20:30 Your server is using etags to send a 304 not modified after the page is in a users cache. If you're having cache problems, try modifying your documents so that their last-modified date on disk is more recent.
– Paul McMillan Nov 5 '09 at 20:37 So you'd recommend just going into each file and changing something small and saving it? Also, how did you find out that the server was sending a 304? – Karl Nov 5 '09 at 20:48.