User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 Even if headers like Cache-Control: no-cache,must-revalidate, Pragma: no-cache, Expires, and Vary: * are present, Firefox and Mozilla will not refetch content if the forward/back buttons are used. Normally, this is a very useful optimization. However, if the content is supposed to vary depending on the page from which it was included, this forward/back caching behavior can result in content being displayed for the wrong page when the forward/back buttons are used. Some of the sites on Runboard, including the one above, use an iframe add-on that looks at the Referer header to present users with a Google search form for searching the current portion of the board. Reproducible: Always Steps to Reproduce: 1. Go to <URL:http://bcjkdramasincalifornia.runboard.com/>. 2. Click on one of the forums, such as "Tech Forum". 3. Press the Back button. Actual Results: 1. A Google search is displayed in the header with no special options beneath. 2. A Google search is displayed in the header with option to search that particular forum. 3. Google search for the forum in step 2 is redisplayed instead of the general search from step 1. Live HTTP headers extension reveals no refetch was attempted. Expected Results: 3. General Google search from step 1 should have been displayed instead of re-using the forum-specific search from step 2. When the content is believed to believed to be referer-dependent, it should not be re-used for different pages. This bug was also verified with Mozilla 1.7.6 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050319] under Windows 2000. Both tests were done when going through a (non-transparent, explicit) proxy server. No workaround was found. (And adding a referer-dependent ID to the URL is not an option for this particular site.) Various combinations of headers were tried, including Cache-Control no-cache and must-revalidate, Pragma: no-cache, Expires, Vary: referer, and Vary: *. No combinations prevented the incorrect forward/back re-use of referer-dependent content. The steps above use an iframe. Similar behavior has been observed with referer-dependent images.
I think you want Cache-Control: no-store
(In reply to comment #1) > I think you want Cache-Control: no-store Thanks very much! That works around the issue for Firefox and Mozilla. However, the current behavior IS a bug since the content is indeed cacheable by user agents that properly handle the Vary header. Servers sending back correct Vary headers will trigger this bug. Until the Vary header is handled, I think Firefox and Mozilla need to treat Vary headers as if Cache-Control: no-store had also been sent. (Although not the Mozilla Org's concern, no-store doesn't workaround the issue for IE/Win32 on HTTP connections. This may be classified as one of the phishing holes that won't be fixed until IE7.) I'll leave it to someone else to come up with examples of security concerns where secure information is sent with a correct Vary header but without the no-store workaround. Again, the bug results in images/iframes being displayed on pages other than that for which they were intended when back/forward are used.
There is definitely generic support for the Vary header in Mozilla. "Vary: Referer" should in fact work. It sounds to me as though you believe that "Vary: Referer" should apply to the back/forward case, when in fact it need not. RFC 2616 specifies that User-Agents may show the user the pages that they previously viewed when they navigate back. Session history implementations need not conform to HTTP/1.1's caching rules. The only exception is the "cache-control: no-store" header since the User-Agent cannot restore what it does not store. This bug is INVALID.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → INVALID
(In reply to comment #3) > It sounds to me as though you believe that "Vary: Referer" should apply to the > back/forward case, when in fact it need not. RFC 2616 specifies that > User-Agents may show the user the pages that they previously viewed when they > navigate back. If you read RFC2616 very narrowly as applying to each resource individually and not in combination, that's true. But I think the intention of the language is that when you hit the back button, it's OK to see the page (including images and iframes) that was previously displayed. As RFC2616 says: >> Rather, a history mechanism is meant to show exactly what the user saw at the time when the resource was retrieved. The consequence of this bug is that users, upon hitting back/forward, may see images, iframes, sounds, video and so forth from a mix of pages that have been retrieved and not the resources that are meant to go with that particular page.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
(In reply to comment #3) > This bug is INVALID. A followup note: I knew when opening this bug report that this is not really a problem with the cache but rather with the back/forward session history mechanism. I chose the Network: Cache component because I don't know what component session history belongs to. I would be happy to have this bug moved to a more appropriate component.
> I don't know what component session history belongs to. History: Session doesn't seem all that unlikely to me ;)
(In reply to comment #6) > > I don't know what component session history belongs to. > > History: Session doesn't seem all that unlikely to me ;) Thanks, and apologies to all for my oversight.
Component: Networking: Cache → History: Session
QA Contact: networking.cache → history.session
As I said before this bug as desribed in comment #0 is invalid or maybe wontfix. We have defined our back/forward behavior to intentionally disregard HTTP cache control logic (except for the no-store case) so that users may see what they previously saw. It is true that some content may not be in the cache when the user navigates back to a page, and that may result in a mixture of old and new content. That is indeed a limitation of the session history implementation. Ideally, the session history implementation would hold onto references to all of the content for previous pages so that it can restore the pages completely, but that has significant memory usage implications. There may be a bug about solving that problem elsewhere. I don't think this bug should be morphed into that bug. Is it the case that "Cache-control: no-store" does not afford you the capability you need to prevent Firefox from loading content from its cache when the user pressed the back button?
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago → 13 years ago
Resolution: --- → WONTFIX
(In reply to comment #8) > As I said before this bug as desribed in comment #0 is invalid or maybe wontfix. > > We have defined our back/forward behavior to intentionally disregard HTTP cache > control logic (except for the no-store case) so that users may see what they > previously saw. It is true that some content may not be in the cache when the > user navigates back to a page, and that may result in a mixture of old and new > content. ... > Is it the case that "Cache-control: no-store" does not afford you the capability > you need to prevent Firefox from loading content from its cache when the user > pressed the back button? no-store does indeed workaround the issue for me, personally, since I control the site generating the referer-dependent content. But I would like to leave the bug open as at least a wishlist item to be fixed sometime down the road. Framing the issue as one of stale content understates the problem since it also can result in content being displayed for the wrong page/site. Example: * User visits site A that includes images or other resources from site C meant for site A. * User visits site B that includes images ... from site C meant for site B. * User, upon hitting the forward/back button on site A, can suddenly see a page from site A but containing images and other resources meant for site B substituted for site A's images and other resources. I think the cross-site possibility makes this issue more serious than if stale content were the only hazard.
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
You need to log in before you can comment on or make changes to this bug.