Caches no-cache pages. (Source of img is not reloaded from server but is taken from cache)




16 years ago
4 years ago


(Reporter: imega, Unassigned)



Windows 2000

Firefox Tracking Flags

(Not tracked)




(3 attachments)



16 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130

From server this header is send (PHP):
header ("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
header ("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT");
header ("Cache-Control: no-cache, must-revalidate");
header ("Pragma: no-cache");
 but Mozila 1.2.1 cache the page and no refresh it
 in Mozila 1.0 - was OK (refreshed)
 in Netscpae 4.5 is OK (refreshed)
 in IE 5,6 is OK (refreshed)

Reproducible: Always

Steps to Reproduce:
1.Load page (page contains headers for no cache) in page is img tag with href 
to dynamic php (page contains headers for no cache + Content-type: image/png )
2.OnLoad page start timer
3.OnTimer change img src (document.frm.myimg.src = /same php page/)

Verry sorry for last report (not complete). - is a stupide test, bat is easy
(The hours have to go !!!)
Test is avalible to 12.06.2002 (MM.DD.YYYY)

Comment 1

16 years ago
*** Bug 183450 has been marked as a duplicate of this bug. ***

Comment 2

16 years ago
what are your Mozilla cache settings ? Prefs -> Advanced -> Cache
Assignee: aaronl → gordon
Component: Accessibility APIs → Networking: Cache
Keywords: testcase
QA Contact: dsirnapalli → tever

Comment 3

16 years ago
Using all (4) switch from:
Prefs -> Advanced -> Cache
But this switch not important with the headers.
(I think so. - in IE and Netscape setting cache for this example is not 

Comment 4

16 years ago
I get the exact same behavior at in 1.1 and 1.2.1

If I view the page, leave the browser open overnight, and refresh the page, I
don't see the new page.  This is with the cache setting to "Every time I view
the page" or "When the page is out of date".  Hitting reload has no effect--the
only way I've discovered to clear the problem is closing and reopening the browser.

Telnetting directly to 80 and entering:
GET / HTTP/1.1

brings back proper date and expiration time headers.

Comment 5

16 years ago
Handling of HTTP headers is more closely related to the HTTP component.
Assignee: gordon → darin
Component: Networking: Cache → Networking: HTTP
QA Contact: tever → httpqa


14 years ago
Summary: Cache no-cahe pages. (Source of img is not refreshed from server (is taked from cache)) → Cache no-cache pages. (Source of img is not reloaded from server but is taken from cache)

Comment 6

14 years ago
The Mozilla browser does not appear to respect cache-control HTTP headers or
<META HTTP-EQUIV> tags, regardless of cache settings in Edit->preferences.

I've searched the following resources for information about this, but haven't
found anything beyond what I'm already using (HTTP headers and HTTP_EQUIV
	 * Mozilla 1.7 help
	 * Mozilla 1.7 known issues list
	 * Mozilla FAQ
	 * Mozilla troubleshooting guide 

   Solaris 8
   Apache 1.3
   Perl 5.6 CGI scripts generating web pages to display database content

   Windows 2000, Version 5.0, Build 2195, Service pack 4
	Mozilla 1.7
	  ->  Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
   (also tested with Mozilla 1.5 and 1.6)

  My project uses perl CGI scripts on the server to generate web pages showing
  the output of database searches.  These web pages include links to other
  CGI scripts, which generate further output.  When I click on Mozilla's
  BACK button from the secondary output, the first CGI script is NOT re-run;
  instead, Mozilla displays an old copy of the previous output.

The complete HTTP headers output by my perl CGI scripts are:
   content-type: text/html; charset=ISO-8859-1
   cache-control: no-cache

I also tried adding the following two HTTP headers:
   Cache-control: max-age=0
   Pragma: no-cache
and using <META HTTP-EQUIV...> tags instead, but nothing works.  Even the old
<META HTTP-EQUIV="Expires" CONTENT="1"> that works with Netscape 4.76 has no
effect on Mozilla.

IE 5.x and 6.x also disregard cache-control, so we're stuck with Netscape 4.76,
but are increasingly concerned about getting any support for it, and it has
its own drawbacks and limitations we'd like to get away from.

H. Pierce,
Medtronic, Inc.
(In reply to comment #6)
>When I click on Mozilla's
>   BACK button from the secondary output, the first CGI script is NOT re-run;
>   instead, Mozilla displays an old copy of the previous output.

you want Cache-Control: no-store, I think

Comment 8

14 years ago
I tried the "no-store" cache control header, as suggested in your email, but it
made no change to Mozilla's caching behavior.  I've also tried setting the cache
size to zero on the client side (Edit -> preferences -> Advanced -> cache), but
Mozilla still caches the CGI-generated output.

H. Pierce, Medtronic 

Comment 9

14 years ago
Hmm.. WORKSFORME.  Can you please provide a Mozilla HTTP log using the steps
described here:

If you attach the log output to this bug, then we may be able to determine from
the log file why it happens that Mozilla continues to cache your page despite
the measures you have taken.  Thanks!

Comment 10

14 years ago
Hmm... this could also be an image loader bug.  The HTTP log file will help us
determine if that is indeed the case (i.e., perhaps the image loader is not even
making a HTTP request).

Comment 11

14 years ago
Created attachment 152549 [details]
Mozilla HTTP log demonstrating cache problem

The log you requested to determine why Mozilla 1.7 is caching cgi-generated
output even when no-cache headers are used.

Comment 12

14 years ago
In the log file, I see no occurance of a no-cache header.  I see one occurance
of 'Cache-control: no-store', which is returned for the URL:

The result of that URL is a text/html document.  I never see the browser request
that document again.  That suggests that you never re-visited the page, via the
back button or otherwise. 

Can you please explain the steps that you did to produce this log file?  Is
there any chance that you can post a live testcase on the web somewhere such
that others like myself can test it out?

Comment 13

14 years ago
Created attachment 152634 [details]
test cases showing the problem

This application and much of the data in it is proprietary, so I cannot put it
on a publicly available server where you can test it directly.

Comment 14

13 years ago
I can reproduce this bug in Mozilla Firefox 1.0.2 but for me the problem is not
an image, but the page itself. I extract information from a MySQL database on a
page, the user can change these information and save them via POST. If i visit
the same page, Mozilla does not refresh the page when i visit it again. I have
to press refresh a couple of times (I suppose it has something to do with the
age of the last cache) and then it refreshes correctly and the page shows the
changes as it should. As Oliver, i've tried several 'tricks' to get it to work,
but Mozilla seems determined to override any HTTP headers, or HTML meta tags.
Internet Explorer correctly refreshes the page every time when using
Cache-Control, Pragma: no-cache or 'expires' meta tag.

Comment 15

13 years ago
I am using firefox 1.0.6.  I have a page that contains <img src="dynamic.gif">,
where dynamic.gif changes based on orders.  Firefox caches the image and
displayed  the old image even though it fetches new data from the server.  

Comment 16

13 years ago
I am using firefox 1.0.4. I have pages that load images that are dynamically produced charts, and submitting form changes to the page change the chart image. Sometimes (but not always), firefox uses a cached image, despite the fact that the images are delivered with Expires:0, Cache-control:must-revalidate, and valid Etag headers which change each time the image changes.

Sorry, it's a complicated web application on private network and not possible to reference from Internet. To reproduce, you'd need something that dynamically generates changing images with the right headers, and a referencing page.

For me, 95% of the time firefox loads the image again. It's just occasional. Funnily enough, my page sometimes does not include an image (if certain settings are made), and it seems that whenever this happens, the next change (which reintroduces the image) will consistently cause an old image to be fetched from cache.

Comment 17

12 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking

Comment 18

11 years ago
You have to use these headers in this exact order for Mozilla:

Cache-Control: no-store, no-cache, must-revalidate
Expires: Sun, 10 Feb 2002 16:00:00 GMT
Pragma: no-cache

Be careful with PHP, it defaults to sending out it's own no-cache headers which will not be recognized by Mozilla properly. Get Firebug to analyze the headers.
Pragma: no-cache is not meant for use in a response... see RFC 2616 14.32. cache-control should be enough.

Comment 20

11 years ago
I know, I'm just stating what works after hours of trials. The order of the headers shouldn't matter either, but it does, Mozilla isn't exactly strictly RFC compliant.
if that Pragma header is required, it would be great if you could file a bug on that. and perhaps another bug on the fact that the ordering makes a difference. thanks!

Comment 22

11 years ago
I posted the info under several open caching bugs, I didn't necessarily feel that yet-another-caching-bug-report would get any attention. The part that can bite people is that PHP defaults to sending out no-cache headers that Mozilla won't recognize. Putting header() calls in your code with the headers in the exact order I specified still won't work if you let PHP send out it's own no-cache headers. So, you have to have the right headers in the right order and the right PHP config to make it work. This bug exists in the newest ( version of Mozilla.

If you're using PHP, you need to make sure the php.ini looks like this:

   ; Set to {nocache,private,public,} to determine HTTP caching aspects
   ; or leave this empty to avoid sending anti-caching headers.
   session.cache_limiter =

Yes, that's correct, don't set it equal to anything at all. No, that's not the same as commenting it out. It must look exactly like that to suppress the default no-cache headers.

In your PHP code you need:

   header("Cache-Control: no-store, no-cache, must-revalidate");
   header("Expires: Mon, 26 Jul 1997 05:00:00 GMT");
   header("Pragma: no-cache");

I spent hours debugging this at work, hopefully someone will benefit.
Oh. The summary of this bug was highly misleading... you're right, this seems like the correct bug.
Summary: Cache no-cache pages. (Source of img is not reloaded from server but is taken from cache) → Caches no-cache pages. (Source of img is not reloaded from server but is taken from cache)

Comment 24

8 years ago
I just had a client hit this bug today.  They loaded the site last week. The site's main content is a swf that is loaded dynamically, via swfobject.  The location of the swf is specified as a string in a javascript file.  Between last week and now, the only change has been to rename the swf and change the corresponding string in the javascript file.  Client loads the page today, gets a blank screen, because firefox didn't issue a request to the server to see if the javascript file changed (while the main html page didn't ).  My understanding is that this is a violation of rfc2616, section 14.9.1:
"If the no-cache directive does not specify a field-name, then a cache MUST NOT use the response to satisfy a subsequent request without successful revalidation with the origin server"
The javascript file has "Cache-Control: no-cache" specified in its header.  I've attached the relevant apache logs.

Let me know if there is anything else that could help, or where in Firefox the relevant code is (I'd be happy to propose a patch if people point me in the right direction).  Looking forward to closing this one.

Comment 25

8 years ago
Created attachment 477557 [details]
logs demonstrating that firefox isn't validating its cached content

sorry for the scrubbing, but it should still get the message across.

Comment 26

8 years ago
this affects v3.6.10 (as well as, I assume, all prior versions since it was first reported).
Dupe this to 350022 ?
Component: Networking → Networking: Cache
QA Contact: networking → networking.cache
Whiteboard: dupeme? 350022
This bug is about images.  Bug 350022 is about radio buttons.  How are they related?
Component: Networking: Cache → ImageLib
QA Contact: networking.cache → imagelib
seemed related to similar cache behavior on the surface, but doesn't look like it given the cause now identified for 350022. removing whiteboard
Whiteboard: dupeme? 350022


6 years ago
Duplicate of this bug: 501718
You need to log in before you can comment on or make changes to this bug.