338542 - an image with 'Cache-control: no-store' not reloaded when loading a page from bfcache (e.g. Back button)

Status: NEW

(Core :: Graphics: ImageLib, defect, P3)

Description

[Frank Muennich]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

I'm displaying a dynamic image (CAPTCHA-image) that sends the following HTTP headers:

Cache-Control: no-cache
Cache-Control: must-revalidate
Cache-Control: no-store
Cache-Control: private
Expires: +a random expiry date in the past!

However, when the user is sent to another adress (or types something in the adress bar) and goes back to the original site via the back-button of the browser, the old image is still displayed although Mozilla should have honored the must-revalidate and no-store directives and therefore should have gotten the image once more from the server (which would then have been another captcha-image)

Reproducible: Always

Steps to Reproduce:
1. Browse to http://www.frank-muennich.com/cacheproblem/testingmozilla.php
2. Remember the code of the image
3. Type something into the adress bar and surf to it (e.g. yahoo.com)
4. Navigate back to the orginal page via the back-button of Mozilla
5. Compare the image - it's the same, although it should be re-loaded from the server

Actual Results:  
The image is taken off the cache.

Expected Results:  
The image should be reloaded from the server.

I've already looked into the following pages:

http://www.mozilla.org/projects/netlib/http/http-caching-faq.html
https://bugzilla.mozilla.org/show_bug.cgi?id=328835
https://bugzilla.mozilla.org/show_bug.cgi?id=261312
https://bugzilla.mozilla.org/show_bug.cgi?id=112564

I appreciate any comments that help me implement something from a web-designer perspective!

Comment 1

[Jesse Ruderman]

I see the same using Mac OS X and Firefox trunk.

Comment 2

[Frank Wein [:mcsmurf]]

bryner: Do you know if bfcache/fastback respects a no-store/no-cache/must-revalidate/etc. Cache-Control header on a single element on a page (for example a image) when the site itself may be cached? It seems in this Bug here bfcache just ignores the Cache-Control header of the image.

Comment 3

[WADA:World Anti-bad-Duping Agency]

> 4. Navigate back to the orginal page via the back-button of Mozilla
> 5. Compare the image - it's the same, although it should be re-loaded from the
server

Default of "bfcache" option is ON.
What will happen when next options are set to ZERO thru about:config?
 browser.sessionhistory.max_total_viewers=0
 browser.sessionhistory.max_viewers=0
(Please clear cache after option change, so as not to misunderstand test result.)
Watching of HTTP flow by LiveHTTPHeaders and viewing of cache information thru about:cache will help your analysis.
 http://livehttpheaders.mozdev.org/index.html

Comment 4

[WADA:World Anti-bad-Duping Agency]

To Frank Muennich(bug opener):

For design of "bfcache", see MozillaZine's news article, "Ben Goodger Explains Higher Memory Usage in Firefox 1.5", and read his Blog pointed in it first.
http://www.mozillazine.org/talkback.html?article=8019
http://weblogs.mozillazine.org/ben/archives/009749.html

Following is a part in his Blog.
> To improve performance when navigating (studies show that 39% of all page
> navigations are renavigations to pages visited < 10 pages ago, usually using
> the back button), Firefox 1.5 implements a Back-Forward cache that retains the
> rendered document for the last few session history entries.
According to this, "Fast Back & Forward" looks to simply re-display rendered page data kept in bfcache. (Similar to tab click other than current tab, instead of internal reloading when before "Fast Back & Forward" or bfcache=OFF.)
I don't know whether this is violation of Cache-Control:no-store for a part(<img> in your case) of HTML or not.
Please note that no HTTP flow level violation is involved, because no HTTP GET is issued by Firefox then no HTTP flow occurs. 

Comment 5

[Frank Muennich]

(In reply to comment #4)

> I don't know whether this is violation of Cache-Control:no-store for a
> part(<img> in your case) of HTML or not. Please note that no HTTP flow level
> violation is involved, because no HTTP GET is issued by Firefox then 
> no HTTP flow occurs. 

I appreciate your comment. However, to me personally I'm much more interested in the aspect of Cache-Control:must-revalidate.  The RFC 2616 is quite clear and specific about this (14.9.4 Cache Revalidation and Reload Controls)

... When the must-revalidate directive is present in a response received by a cache, that cache MUST NOT use the entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. (I.e., the cache MUST do an end-to-end revalidation every time, if, based solely on the origin server's Expires or max-age value, the cached response is stale.) [...] In all circumstances an HTTP/1.1 cache MUST obey the must-revalidate directive; in particular, if the cache cannot reach the origin server for any reason, it MUST generate a 504 (Gateway Timeout) response.


In my opinion should it be irrelevant whether the data is taken off the regular cache or the bfcache/fastback cache, because it should not be taken off a cache in the first place. Whether the data is also stored or not is not of particular concern to me, although of course efforts should be made to also honour that directive.

There has to be a way from a webdesigner's view to ask of Mozilla to display an item (whether page or image) once and only once. Of course I could implement Javascript or Flash, but not everyone has Flash or Javascript etc. enabled (or even available).

Comment 6

[Jesse Ruderman]

The spec paragraph about must-revalidate you pasted says nothing about session history.  I think it was decided long ago within the Mozilla project that hitting the back button does not constitute a "subsequent request" for the page.  On the other hand, the spec for no-store explicitly says we don't have to honor it for session history, and we do honor it because of pressure from banks.  Anyway, that's best discussed elsewhere since it's irrelevant to the issue of bfcache not honoring no-store for images.

A simple workaround for this bug (assuming it is a bug) is to use no-store for both the page and the image.

Comment 7

[Brian Ryner (not reading)]

(In reply to comment #2)
> bryner: Do you know if bfcache/fastback respects a
> no-store/no-cache/must-revalidate/etc. Cache-Control header on a single element
> on a page (for example a image) when the site itself may be cached? It seems in
> this Bug here bfcache just ignores the Cache-Control header of the image.
> 

I don't believe it checks for that -- it only checks the cachability of the toplevel document and frames/iframes, and stores the entire presentation if that checks out.

Comment 8

[Frank Muennich]

Funny thing: if the entire webpage is served with no-cache, no-store and must-revalidate headers, the file itself is - as it should - reloaded from the server. The image, however, is not and taken off the cache! I have no idea how I could resolve this anymore.

Could someone please verify this?

Comment 9

[Tim Heckler]

I also find that Firefox is still not HTTP 1.1 compliant in the way it handles the cache-control: no-store directive.  IE is fully compliant and will not allow a browser to save or cache a file if that directive is listed in the HTTP header tab in IIS.  I have been trying to stop people from saving Flash videos out of their cache, and it works correctly with any browser that is fully HTTP 1.1 compliant and adheres to the cache-control http header restrictions.   When is this going to be fixed in Firefox?  I have tested in multiple versions, and Firefox does not conform to the HTTP 1.1 specification for handling headers in any of them.  Please put someone on this bug since it is a big security violation for content providers to let users with Firefox not respect the content restrictions.

Comment 10

[WADA:World Anti-bad-Duping Agency]

> I'm displaying a dynamic image (CAPTCHA-image) that sends the following HTTP
> headers:
> Cache-Control: no-cache
> Cache-Control: must-revalidate
> Cache-Control: no-store
> Cache-Control: private
> Expires: +a random expiry date in the past!

To Frank Muennich(bug opener):
Does above mean "all of such headers were REALLY sent from server to Firefox"?
Or above means header("cache-control: ...") of PHP is called multiple times?
If latter, see Bug 327790 Comment #24. Same case as Bug 327790?

Comment 11

[WADA:World Anti-bad-Duping Agency]

FYI.
Bug 327790 Comment #1 points to following document. "page" in this document looks to be HTML.
> https://developer.mozilla.org/en/Using_Firefox_1.5_caching
Following is two of conditions that Firefox doesn't cache pages in bfcache.
> # the page sets "cache-control: no-store"
> # the page sets "cache-control: no-cache" and the site is HTTPS.

(In reply to comment #8)
> Funny thing: if the entire webpage is served with no-cache, no-store and must-revalidate headers, 
> the file itself is - as it should - reloaded from the server.

This is explained by above spec of bfcache.
 
> The image, however, is not and taken off the cache! I have no idea how I could resolve this anymore.

"cache or not cache of image" depends on Cache-Control: response for image, instead of Cache-Control: for HTML.
What Cache-Control: header does your server return for HTTP GET of image?
Do you use PHP code like next for URL to get image file?
   <img src="http:.../abc.php">
   <?php 
         header('Cache-Control: no-cache, no-store, must-revalidate');
         header('Content-Type: image/jpeg') ;
         readfile('abc.jpg') ;
   ?>

Comment 12

[Jan Braun]

Please read read rfc 2616 sections 13.13 and 14.9.2 and stop claiming a browser was required to throw anything away because of cache-control directives. (In fact, ff insisting on revalidating pages I was going "back" to was, while legal, one of the annoyances that drove me away from using it.) Certainly INVALID, I'd hope WONTFIX.

Comment 13

[Joe Drew (not getting mail)]

This might be a dupe of 490949? Or at least fixed by it?

Comment 14

[Nickolay_Ponomarev]

Adjusting summary; this doesn't seem to be related to bug 490949.

Comment 15

[Patrick McManus [:mcmanus]]

so in general we do force validations for things that are no-store and I can confirm this bug at https://www.ducksong.com/misc/aa.html

No http channel is being formed (which would revalidate based on the no-store), so I presume the cache that's being too strong is in imglib.