450966 - Firefox 3 caches pages with Cache-Control: no-cache,no-store

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Garret Wilson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I have pages 100% generated by the server, containing the following HTTP header:

Cache-Control: no-cache,no-store

According to RFC 2616, as well as http://developer.mozilla.org/en/docs/Using_Firefox_1.5_caching , this should be sufficient to prevent caching. It was sufficient to prevent caching on earlier versions of Firefox.

Yet when I use JavaScript to change the location to another page using window.location.href=newPage.html , and then I come back to firstPage.html using the browser back button, Firefox 3 does *not* issue a new HTTP GET and instead uses a cached version of the page firstPage.html.

This is flatly wrong.

This is new erroneous behavior.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Garret Wilson]

Other note: this behavior is seen on localhost; it is unknown if it occurs on remote servers.

It seems that Firefox 3's caching behavior is screwed up across the board. The following may or may not be related:

http://www.garretwilson.com/blog/2008/08/10/firefoxwindowlocationreloadcache.xhtml

Comment 2

[Matthias Versen [:Matti]]

there is nothing screwed up and is working as expected as far as i know.
Please include a http log.
http://www.mozilla.org/projects/netlib/http/http-debugging.html

Comment 3

[Ria Klaassen (not reading all bugmail)]

Could you attach a testcase for regression testing?

Comment 4

[William Halliburton]

I can confirm this bug, but I believe the cause is FireBug. FF 3.0.1 without firebug observes caching settings. When Firebug 1.2.0b13 is enabled, the no-cache settings are silently ignored. 

Comment 5

[William Halliburton]

Related to Bug 441751

Comment 6

[Garret Wilson]

I'm running Firebug 1.2.0b7, so that could very well be the problem. Oh, that would make me irritated (but would restore my faith in Firefox).

Comment 7

[William Halliburton]

I moved back to Firebug 1.2.0b6 and that fixed the problem. Looks very recent. The firebug backtracker (sorry no url) has several very recent bug reports and I would hope they are working on it now. 

Comment 8

[Matthias Versen [:Matti]]

Thanks, marking invalid (extension bug)
Please always check an issue with the firefox safemode before reporting a bug.
- http://kb.mozillazine.org/Safe+mode

Comment 9

[d.corsello]

I have used the following PHP code to add headers to data files that are read into Flash web apps in an attempt to prevent the data from being cached:

header("Expires: Mon, 20 Dec 1977 00:00:00 GMT");
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header("Cache-Control: no-store, no-cache, must-revalidate");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");
header("Content-Type: [insert data type here]");
readfile("filename");

When the above code is executed, a dump of the PHP output is stored in Firefox 3.0.x's memory cache.

I have confirmed that this occurs in safe mode in ver. 3.0.x.  

Flash doesn't seem to be the culprit, because a dump is listed in memory cache even when the PHP is executed directly.

In Firefox 2.x, the memory cache listing shows only the names of files that contain the above headers.  Such a file's detail listing doesn't include a dump of its contents.

This problem (or design feature--I'm not sure which it is) makes it impossible to use no-cache headers as a means of keeping relatively sensitive data any more secure than it is when the headers are not present.  If the Content-Type header specifies text data, the results can be easily read visually from the memory cache dump listing. For other Content-Types, the dump can be copied and pasted into a text file, and then massaged and converted into binary format.

In every other browser that I have tested, adding these headers makes files impervious to retrieval from browser cache.  Is this a design feature or a bug?

Comment 10

[Eric Lawrence]

When citing RFC2616, you ought to read the whole thing. Back/Forward navigation isn't required to follow the rules for caches.

13.13 History Lists

   User agents often have history mechanisms, such as "Back" buttons and
   history lists, which can be used to redisplay an entity retrieved
   earlier in a session.

   History mechanisms and caches are different. In particular history
   mechanisms SHOULD NOT try to show a semantically transparent view of
   the current state of a resource. Rather, a history mechanism is meant
   to show exactly what the user saw at the time when the resource was
   retrieved.

   By default, an expiration time does not apply to history mechanisms.
   If the entity is still in storage, a history mechanism SHOULD display
   it even if the entity has expired, unless the user has specifically
   configured the agent to refresh expired history documents.