9 years ago
5 years ago


(Reporter: Mike F, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: 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: 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.


9 years ago
Severity: normal → major

Comment 1

9 years ago
Care to give an example of such a website ?

Comment 2

8 years ago
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.

Comment 3

8 years ago If you claim to verify this issue, you should at least supply a URL where this happens

Comment 4

8 years ago
I'd love to, Jo. but as mentioned, it's in internal app I'm working on, so 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.

Comment 5

8 years ago
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.

Comment 6

8 years ago
I have also witnessed this behavior. I created a php script that sets the following header, Cache-Control: max-age=300. Then the script prints the current time as a UNIX timestamp. I then created a HTML/JavaScript page that makes 5 XHR  GET requests 3 seconds apart to the PHP script. These are the results:

Normal request
Response Timestamp: 1255458004

Request with If-Modified-Since header
Response Timestamp: 1255458007

Normal request
Response Timestamp: 1255458004

Request with Cache-Control: max-age=0, no-cache header
Response Timestamp: 1255458004

Normal request
Response Timestamp: 1255458004

As you can see from the above results the correct timestamp is returned on the second request, but the response is not cached as it should be, instead all subsequent requests use the cached original request. This test also shows that the max-age=0 and no-cache Cache-Control directives have no effect.

Comment 7

8 years ago
Created attachment 406053 [details]
Relevant http debug log

Attaching an HTTP debug log of the 5 XHR requests.
dupe of bug 183470?


5 years ago
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 183470
You need to log in before you can comment on or make changes to this bug.