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

Status: UNCONFIRMED

(Core :: Graphics: ImageLib, defect)

Description

[imega]

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).
http://www.imega.cz/testhour.php - is a stupide test, bat is easy
(The hours have to go !!!)
Test is avalible to 12.06.2002 (MM.DD.YYYY)

Comment 1

[Olivier Cahagne]

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

Comment 2

[Olivier Cahagne]

what are your Mozilla cache settings ? Prefs -> Advanced -> Cache

Comment 3

[imega]

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 
importante).

Comment 4

[Paul J. Ste. Marie]

I get the exact same behavior at http://gpf-comics.com 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 gpf-comics.com 80 and entering:
GET / HTTP/1.1
Host: gpf-comics.com

brings back proper date and expiration time headers.

Comment 5

[gordon]

Handling of HTTP headers is more closely related to the HTTP component.

Comment 6

[Howard E. Pierce]

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
tags):
	 * Mozilla 1.7 help
	 * Mozilla 1.7 known issues list
	 * Mozilla FAQ
	 * Mozilla troubleshooting guide 

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

Client:
   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)

Scenario:
  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.

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

(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

[Howard E. Pierce]

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
[e-mail] 

Comment 9

[Darin Fisher]

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

  http://www.mozilla.org/projects/netlib/http/http-debugging.html

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

[Darin Fisher]

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

[Howard E. Pierce]

Attachment: 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

[Darin Fisher]

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:

http://toby.pace.medtronic.com/cgi-bin/VersionHistory?Lang=tools&ObjIDver=10870-007.log

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

[Howard E. Pierce]

Attachment: 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

[Rene Gundersen]

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

[cctang0]

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

[Dave Clark]

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

[Darin Fisher]

-> default owner

Comment 18

[Steve Garvey]

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.

Comment 19

[Christian :Biesinger (don't email me, ping me on IRC)]

Pragma: no-cache is not meant for use in a response... see RFC 2616 14.32. cache-control should be enough.

Comment 20

[Steve Garvey]

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.

Comment 21

[Christian :Biesinger (don't email me, ping me on IRC)]

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

[Steve Garvey]

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 (2.0.0.2) 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.

Comment 23

[Christian :Biesinger (don't email me, ping me on IRC)]

Oh. The summary of this bug was highly misleading... you're right, this seems like the correct bug.

Comment 24

[Bobby Powers]

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

[Bobby Powers]

Attachment: logs demonstrating that firefox isn't validating its cached content

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

Comment 26

[Bobby Powers]

this affects v3.6.10 (as well as, I assume, all prior versions since it was first reported).

Comment 27

[Stephanie Daugherty [:sdaugherty]]

Dupe this to 350022 ?

Comment 28

[Boris Zbarsky [:bzbarsky]]

This bug is about images.  Bug 350022 is about radio buttons.  How are they related?

Comment 29

[Stephanie Daugherty [:sdaugherty]]

seemed related to similar cache behavior on the surface, but doesn't look like it given the cause now identified for 350022. removing whiteboard

Comment 31

[David Spector]

Firefox still seems not to reload PHP-generated pages using a local server in response to the Ctrl-
F5 keystroke, 16 years after this report was submitted. To be clear, new edits to the <?...?> program in a local PHP page do not have any visible effect after Ctrl+F5. PHP seems only to be called when the tab is closed and a new tab started. This probably applies to all content generated by PHP, including text, images, etc.

I use the "PHP as a module" not any of the CGI integration methods, as follows:

LoadFile "C:/WAMP/php/libpq.dll"
LoadModule php7_module "C:/WAMP/php/php7apache2_4.dll"

In my opinion, this bug reflects a fundamental failure to follow standards, and leads to stale output being displayed in spite of the use of Ctrl+F5, which is documented as forcing the page to be reloaded.

There is nothing wrong with using a cache for true GET data, which does not change for a given Query argument. But in real life, GET is frequently used for freshly-calculated pages instead of POST for convenience.

In my verification, I added the following Apache directives to my configuration file, and they did not work for me:

<FilesMatch "\.php$">
Header set Cache-Control: no-store
Header merge Cache-Control: no-cache
Header merge Cache-Control: must-revalidate
Header set Expires: "Sun, 10 Feb 2002 16:00:00 GMT"
Header set Pragma: no-cache
</FilesMatch>

Also, use of about:config > browser.cache.check_doc_frequency and about:config > network.dnsCacheExpiration had no effect, which kind of makes sense since Apache is serving from an IP address (127.0.0.1), so no DNS should be involved.

Windows 10, Apache/2.4.33 (Win32), PHP/7.0.30, Firefox 61.0 (64 bit)

Comment 32

[Boris Zbarsky [:bzbarsky]]

David,

If you have a reproducible testcase for whatever it is you see, I suggest filing a separate bug for the behavior you are seeing and attaching logs generated per the instructions at <https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging>.  Please make sure to include information about what URL it is that you're seeing end up with stale data.  If you add me to the cc list on the new bug, I will direct it to the right people.

Comment 33

[David Spector]

Boris, I have followed your instructions in full detail. The new bug is 1473708. Please add yourself to the cc list, as I do not want to experiment with manipulating the cc list as I might mess something up.

Comment 34

[Boris Zbarsky [:bzbarsky]]

Thanks, I'll follow up there.