If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Browser.cache.memory can't be disabled remotely with HTTP headers

RESOLVED DUPLICATE of bug 441751

Status

()

Core
Networking: Cache
RESOLVED DUPLICATE of bug 441751
9 years ago
9 years ago

People

(Reporter: Fabrizio Balliano, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.4) Gecko/2008111318 Ubuntu/8.10 (intrepid) Firefox/3.0.4

I'm building an application which absolutely needs to disable all browser caches, I set a lot of HTTP headers but firefox memory cache never gets disabled but I think it should obey to HTTP cache headers.

Reproducible: Always

Steps to Reproduce:
this is a snippet of php code i use to disable all the caches

$gmdate = gmdate( "D, j M Y H:i:s" );
header("Pragma: no-cache");
header("Last-Modified: $gmdate GMT");
header("Expires: $gmdate GMT");
header("Cache-Control: must-revalidate, post-check=0, pre-check=0, max-age=0, private, no-cache, no-store");
Actual Results:  
sites still get cached

Expected Results:  
site is NOT cached
(Reporter)

Comment 1

9 years ago
you can try this PHP script to check the bug:


-----------------------------
<?php
session_start();
header('Pragma: no-cache');
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");                  // Date in the past
header('Last-Modified: '.gmdate('D, d M Y H:i:s') . ' GMT');
header('Cache-Control: no-store, no-cache, must-revalidate');     // HTTP/1.1
header('Cache-Control: pre-check=0, post-check=0, max-age=0');    // HTTP/1.1
if (!isset($_SESSION['test'])) {
        echo "<a href='index.php'>First Run</a>";
        $_SESSION['test'] = TRUE;
} else {
        echo "Second Run";
}
?>
-----------------------------

open firefox, poi to the address of the script, it will output "first run", click on the link, it will echo "second run" now hit BACK.
- if you've memory cache enabled it will echo "first run"
- if you don't have memory cache it will echo "second run" (this is the right behavior cause the script is sending HTTP headers to disable cache)

Updated

9 years ago
Component: General → Networking: Cache
Product: Firefox → Core
QA Contact: general → networking.cache

Comment 2

9 years ago
I can confirm this bug (ignoring the link-to-self confusion) with the PHP as given.  If I remove the second Cache-Control header, it starts working fine.  So this seems to be a dup of bug 327790.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 327790
(Reporter)

Comment 3

9 years ago
actually i don't think it's a dup of bug #327790, look at this page:
http://p4a.crealabsfoundation.org/bfcache/index.php
it's generated with a php stateful framework, so when you click a row on the table and reload the row pointer still points to the same row

i modified all the headers to respect the indications or bug #327790, all can be checked with liveheaders

but clicking back shows that the page is still being cached.

note that the page is not driven by real links but by a big single form which is submitted on every click
So what exactly are the steps to reproduce with the testcase from comment 3?  I load it, I get back a page that says nothing about this bug, or about caching behavior, when I click links and then go back.
(Reporter)

Comment 5

9 years ago
- open a new tab
- click http://p4a.crealabsfoundation.org/bfcache/index.php
- click the second row of the table
- click firefox's back button

you should NOT see the previous page but always the same (Internet Explorer has the right behavior, firefox loads the page from bfcache)

if you look at the HTTP headers you'll see that's full of no-cache no-store etc...
If I follow the steps in comment 5, I see a "Loading" indicator when I click back, and the selected row does not change.  I ran under a debugger and we are most certainly not loading from bfcache (due to the presence of the "Cache-control: no-store" header).  Which is as expected.
(Reporter)

Comment 7

9 years ago
hum, i'm on firefox 3.0.4 on linux and i see the buggy behavior
(Reporter)

Comment 8

9 years ago
tried on windows, buggy behavior again, not always on the first click on the application, it happens after a few clicks, second row, first row, second row, back, steps like that, seems not so costant
Oh, right.  3.0.4 still has bug 441751.  Nothing to do with bfcache, and everything to do with what this bug was filed about.
Duplicate of bug: 441751
You need to log in before you can comment on or make changes to this bug.