User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:220.127.116.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729) If the browser.cache.check_doc_frequency is set to default (3), FF does not respect cache-control headers. Stale/Out of date information is then displayed. Reproducible: Always Steps to Reproduce: 1.Go to any site that sends correctly-formed cache-control headers, last-modified headers and/or Etags. The cache-control header should include "must-revalidate". 2.Click on refresh or click the referring link again. 3.Notice that the page refreshes from the cache and sends no data to the server at all. Actual Results: Ensure that your browser.cache.check_doc_frequency is set to default (3) Expected Results: FF should send a "Get" request to the server, with the correct "If-modified", etc. headers. In testing, I am explicitly sending correct headers to the browser using Apache and PHP directives. In all other (non-Mozilla) browsers I've tested, their default settings allow for proper refreshing of changed resources. If the "max-age" header is set to 24 hours, for example, until that 24 hours has elapsed, the page is not updated (whether or not it has changed) because FF refuses to ask the server if the page is fresh or not. This behavior is *not* as per HTTP standards. The default value of browser.cache.check_doc_frequency should be changed to "1" in all distributions in order to compete with other browsers.
Care to give an example of such a website ?
Same issue using Firefox 3.5.2 on WindowsXP Cache control headers, sent via PHP header functions as well as metag tags, are ignored by Firefox 3.5 Verified with Firefox 3.0.12 and IE7 that both honor the cache control headers. No test site available because this was discovered while working on an internal app.
firstname.lastname@example.org: If you claim to verify this issue, you should at least supply a URL where this happens
I'd love to, Jo. but as mentioned, it's in internal app I'm working on, so http://10.0.0.1/test.php is not going to be useful here. I'll try to see if I can narrow down the problem and provide some kind of test case when I'm done with the actual app itself.
Unfortunately, the particular site that I first saw this problem on is no longer hosted on my server, and the PHP code has been completely changed. I will, however, put together a test site to demonstrate the issue. In subsequent monitoring of other sites, I saw that this problem occurs when a previously visited internal link is re-visited while cache is still populated, and sometimes when clicking on the "refresh" button. The problem does *not* occur when doing a [shift] refresh. I will update when I complete test site.
Created attachment 406053 [details] Relevant http debug log Attaching an HTTP debug log of the 5 XHR requests.
dupe of bug 183470?