479181 - Firefox ignores all programmatic attempts to prevent caching of content

Status: RESOLVED DUPLICATE of bug 327790

(Core :: Networking: Cache, defect)

Description

[dspent]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 GTB5 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 GTB5 (.NET CLR 3.5.30729)

I run a website that is required to keep certain content secured from caching on client machines via browser caches.  The website is a coldfusion based site, however we see the same behavior regardless of coding language.

We have added the following lines of code in the head of each page requested:

<CFSET gmt = gettimezoneinfo()>
<CFSET gmt = gmt.utcHourOffset>
<CFIF gmt EQ 0>
   <CFSET gmt = "">
   <CFELSEIF gmt GT 0>
   <CFSET gmt = "+" & gmt >
</CFIF>
<CFHEADER NAME="Expires" VALUE="Mon, 06 Jan 1990 00:00:01 GMT" />
<CFHEADER NAME="Last-Modified" VALUE="#DateFormat(now (), 'ddd, dd mmm yyyy')# #TimeFormat(now(), 'HH:mm:ss')# GMT#gmt#" />
<cfheader name="Cache-Control" value="no-store, no-cache, must-revalidate" />
<cfheader name="Cache-Control" value="post-check=0, pre-check=0" />
<cfheader name="Cache-Control" value="max-age=0" />
<cfheader name="Pragma" value="no-cache" />
<cfheader name="Cache-Control" value="private" />

The code above gets called when each page is requested.

In IE we delete everything in the cache, access a page and nothing gets cached in the folder.

In Firefox, we remove all items from the disk cache and image and .MP3 files get cached and remain there even after the browser is closed.

Reproducible: Always

Steps to Reproduce:
1.  add the code to prevent caching (using any language or meta tag method available)
2.  clear the browser cache (disk and memory)
3.  access the .cfm .htm .asp etc... templates
4.  Check to see if anything is cached.
Actual Results:  
.MP3 and image files from the webpage are cached

Expected Results:  
nothing should be cached

In previous versions (prior to 3) of firefox this was not the case.
IE does not exhibit this behavior, nor does safari or opera.  We have not checked other browsers than these.

In banking sites, or other sites like ours that are required to keep certain items from being cached on the client computer, this could be considered an extreme security risk.

Comment 1

[Daniel Veditz [:dveditz]]

What's the "GBT5" in your user agent? have you tried this with a stock Firefox run in -safe-mode to eliminate any addons messing around?

How are you loading MP3 files from the webpage? Since Firefox doesn't play those are they being loaded by a plugin? Maybe the plugin is giving us the wrong information?

I know the cache control headers work in general, I don't suppose you could give us a URL that exhibits the problem? Or could you capture a debugging log? http://www.mozilla.org/projects/netlib/http/http-debugging.html
To the list of modules on that page you could add cache:5 to capture caching info.

Comment 2

[dspent]

What's the "GBT5" in your user agent?
I don't know, however it is in every instance of firefox I run.  At home I do have some addons, however at work it is a standard "out-of-the-box" install of firefox, no addons of any kind and the behavior is the same there.  I use firefox on my laptop with no addons and the GBT5 is there as well.

How are you loading MP3 files from the webpage?
On the webpage I host (www.buymybeat.com) we use the wimpy player to actually play the files.  The player however simply plays the file (through a flash interface) by reading it from a directory.  Again as stated in the bug report, IE, Safari and Opera do not cache the .mp3 file.  We have tested this.  If we remove the header code then all of those browser will cache the content.  If we put it back in, then they cache NOTHING.  Firefox on the other hand, without this code, caches everything.  With the code, it caches just the .mp3 files.

I don't suppose you could give us a URL that exhibits the problem?
Sure our site (www.buymybeat.com) however if you go to any site that plays .mp3 files in the same manner as ours you will find the same behavior.  Another site that does this similar to ours is (www.givemebeats.net).

Or could you capture a debugging log?
I will do this and post back later with results....

Comment 3

[dspent]

I ran the debug log but it was empty.  Log.txt showed no results.

Comment 4

[WADA:World Anti-bad-Duping Agency]

> We have added the following lines of code in the head of each page requested:

If added code generates <meta> tag, see Bug 327790 Comment #11.
If added code generates cache related HTTP header(Cache-Control: etc.), read thru Bug 327790 first, please.

Comment 5

[dspent]

I would like to close out this bug report as based on comments in Bug 327790 it is not that FF is ignoring the no cache headers, it appears that it is expecting them in a certain order...the comments in Bug 327790 and also information from the the http rfc 2616 also seem to elude to FF defaulting to caching all content if it receives multiple headers that could conflict with each other.  We can't rule that out.

After reading the comments in Bug 327790 I changed my code from what I had before:

:::::::::: BEFORE CODE :::::::::::::::

<CFSET gmt = gettimezoneinfo()>
<CFSET gmt = gmt.utcHourOffset>
<CFIF gmt EQ 0>
   <CFSET gmt = "">
   <CFELSEIF gmt GT 0>
   <CFSET gmt = "+" & gmt >
</CFIF> 
<CFHEADER NAME="Expires" VALUE="Mon, 06 Jan 1990 00:00:01 GMT" />
<CFHEADER NAME="Last-Modified" VALUE="#DateFormat(now (), 'ddd, dd mmm yyyy')# #TimeFormat(now(), 'HH:mm:ss')# GMT#gmt#" />
<cfheader name="Cache-Control" value="no-store, no-cache, must-revalidate" />
<cfheader name="Cache-Control" value="post-check=0, pre-check=0" />
<cfheader name="Cache-Control" value="max-age=0" />
<cfheader name="Pragma" value="no-cache" />
<cfheader name="Cache-Control" value="private" />

:::::::::::: END OF PREVIOUS CODE ::::::::::::::


TO THIS:

:::::::::::: AFTER READING BUG 327790 REVISED CODE :::::::::::::::::
<!--- First set the GMT variable --->
<CFSET gmt = gettimezoneinfo()>
<CFSET gmt = gmt.utcHourOffset>

<!--- If GMT is ZERO then set gmt to an empty string --->
<CFIF gmt EQ 0>
   <CFSET gmt = "">

<!--- Else, gmt is greater than ZERO set gmt to gmt var prepend + sign>
   <CFELSEIF gmt GT 0>
   <CFSET gmt = "+" & gmt >
</CFIF>

<!--- Instruct Browsers to NOT store or cache page content, VERY IMPORTANT
MAKE SURE THAT FIREFOX BROWSER RECEIVED THESE HEADERS IN THIS ORDER --->
<cfheader name="Cache-Control" value="no-store, no-cache, must-revalidate" />
<CFHEADER NAME="Expires" VALUE="Mon, 06 Jan 1990 00:00:01 GMT" />
<cfheader name="Pragma" value="no-cache" />
<CFHEADER NAME="Last-Modified" VALUE="#DateFormat(now (), 'ddd, dd mmm yyyy')# #TimeFormat(now(), 'HH:mm:ss')# GMT#gmt#" />
<!--- DO NOT ALTER PREVIOUS HEADER CODE ORDER --->

::::::::::::::::::::  END OF REVISED CODE ::::::::::::::::::::

With the revised code the following behavior was observed:

1. access about:cache to determine the disk cache location
2.  open folder location of disk cache
3.  use CLEAR PRIVATE DATA feature to erase/empty current files from the browser cache
4.  access website, and click on one or more .mp3 links to play music
5.  while track is playing through the flash based player, a file named 20C8D5E9d01 appears, the size of this file initially shows 0KB, it is obviously the music file.  However after refreshing the folder contents several times using F5, the maximum size of this file grows to only 496KB.  The size of the music file is approx 5MB
6.  The music is set to play only 90 seconds at which time it stops, a final refresh of the folder contents just before it reaches 90 seconds yields the size to remain at 496KB.
7.  After 90 seconds is reached the music ends, automatically the file 20C8D5E9d01 disappears. EXCELLENT!!!

The question is then raised, what if the user accesses the cache and attempts to play the 496KB file?  We test this theory and observe the following:

1.  We again remove/delete the cache contents of the folder
2.  we play another track from the website
3.  This time a file named 9F62CE88d01 appears, the same file size of 496KB is observed
4.  We try to rename the file to 9F62CE88d01.mp3 and play it in windows media player and quick time player
5.  WMP will attempt to play the file then throws an error that the file is not a valid mp3.  Quick time will not open the file with a similar error.
6.  After 90 seconds this file also disappears. EXCELLENT!!!!

We also tested the same scenarios again but reordered the headers and FF cached the content. which is not what we want to happen.  So it appears order is very important.

So in conclusion we can now verify that firefox is NOT the problem but it would be helpful if maybe Mozilla would publish something official to let web developers know that in order to achieve No store, no cache effect that the developer must send ONLY the headers necessary and in the order shown above.  If they do not use the correct order OR if they send more than is required that FF appears to default to a behavior where it caches the content which is not a BUG but rather an intended behavior which may give the impression that it has ignored the header instructions.

Thanks to WADA and Daniel Veditz for asking the "RIGHT" questions to help us better troubleshoot this issue.  And sorry for posting the bug report which obviously was not needed.

I have marked the status RESOLVED FIXED, however I am not sure if I should use WORKSFORME instead.  As we could have just found a workaround that only works for us.  Please test our theories so that others experiencing this problem can resolve their issues as well.

Comment 6

[WADA:World Anti-bad-Duping Agency]

> :::::::::::: AFTER READING BUG 327790 REVISED CODE :::::::::::::::::
>(snip)
> <cfheader name="Cache-Control" value="no-store, no-cache, must-revalidate" />

Same problem as Bug 327790. Causes are;
a. No check of HTTP headers really sent by server before bug open,
   even though complaints relate to HTTP caching.
b. No manual reading about function which programmer uses in Bug 327790.
c. Not-so-popular/not-so-well-documented spec/design of Fx's bfcache.
   Who can know about the doc at http://developer.mozilla.org during Web design?

FIXED     : Fx's bug existed, and was fixed by known patch.
WORKSFORME: Fx's bug existed, and was fixed by unknown patch.
Closing as DUP of Bug 327790(INVALID) for ease of tracking, although different server system/used language.

> We also tested the same scenarios again but reordered the headers and FF cached the content. which is not what we want to happen.
> So it appears order is very

Order of "Cache-Control: ..., ..., ..." and "Pragma:no-cache"?
Behaviour of client/server, when multiple headers or parameters, conflict headers or parameters, is not so well defined in RFC. If Fx's bug seems to be involved in the phenomenon, open separate bug, please.