|Firefox (and IE) not displaying updates to web site|
Only on work computers
| 1:44 pm on Dec 16, 2009 (gmt 0)|
Ok folks, this is a weird one, and I hope someone may have suggestions. I maintain my company's website, and am in the process of adding new content. So say for example I add a new link to a page to another part of the site. When I refresh my browser (FF, IE(6/7/8) or safari/Chrome/opera) I see the changes fine. However, people here at work who are on a different domain (we are on engineering, they are on the admin domain) fail to see the changes I have made. They see the same issue in FF/IE.
I have had them clear out cache (in both FF and IE) as well as restart their machines. No one seems to have an issue looking at the changes from their home computers. Does anyone have any idea what could be causing the issue?
| 2:13 pm on Dec 16, 2009 (gmt 0)|
My best guess would be a caching proxy somewhere in the 'interface' between engineering and admin, combined with a lack of Cache-Control headers on server responses.
Use the "Live HTTP Headers" for Firefox/Mozilla to view the server response to request for one of these "non-updating" pages. If you don't see a Cache-Control header indicating that the page must be revalidated, then that's the likely cause -- *If* there is a cache in the network.
Ideally, you want your server configured to send the Cache-Control, Last-Modified, Expires, and Etag headers, with max-age defined in the Cache-Control header in addition to the caching policy.
|Cache-Control: private, must-revalidate, max-age=2400 |
Expires: Wed, 16 Dec 2009 17:04:50 GMT
Last-Modified: Wed, 16 Dec 2009 13:34:24 GMT
The caching policy used in the Cache-Control header can and should vary according to the type of resource is being served. Servers can generally be configured to send different cache-policy headers depending on the MIME-type of the requested file, its URL or filesystem location, or combinations of these. HTML pages and resources that are updated as part of the work process should have short expiry times and be marked as "must-revalidate" -- and in some cases should be completely non-cacheable. Other objects such as images and media files may be cacheable over several days or even several weeks (beyond that, the advantages of caching reach a point of diminishing returns.)
There are some fairly good resources on-line for researching this. Try searching for "caching tutorial for Webmasters" and related phrases. But be careful; Some of the Cache-Control header attributes have non-intuitive behavior, and it's important to realize that if you set a very-long caching time on a resource, then once that resource has been cached by a client, you'll have to wait for that time to expire or notify the user to flush his cache before that user will ever see an updated resource. That is, the caching policy is fetched with the resource content today, and that content and its caching policy won't be re-fetched until it expires next week, or next month... You've told that client, "Here it is, don't come back for a month." So keep your cache-times fairly low until you are really comfortable with this whole concept.
Gee, I sure hope you've got a caching proxy in that network. Otherwise this post is kinda long!
| 3:17 pm on Dec 16, 2009 (gmt 0)|
Thanks for the quick response Jim! Here is what Live HTTP headers is seeing for my page:
Also below for the same page (second section before the separator line):
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
| 3:22 pm on Dec 16, 2009 (gmt 0)|
Did you check this from the 'admin side'?
| 3:26 pm on Dec 16, 2009 (gmt 0)|
Not sure what you mean. I loaded up firefox and live http headers and refreshed the page within firefox. The site is hosted via bluehost
| 3:53 pm on Dec 16, 2009 (gmt 0)|
Test the cache-influencing headers from a machine in your network that shows the "non-updating-pages" behavior. I believe you said that "engineering machines show updated pages, admin machines don't," so test and check headers from the "admin side." Then compare and contrast what you see.
| 4:35 pm on Dec 16, 2009 (gmt 0)|
ah! Not enough coffee this morning! hehe I will try that thanks.
| 11:53 pm on Dec 16, 2009 (gmt 0)|
You might also try using the dotted IP address on the "doesn't-work" side of the house in the location bar. Viz: