302996 - forward/back buttons fetch content for other pages even if Vary: Referer used

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, defect)

Description

[Charles C. Fu]

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.

Comment 1

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

I think you want Cache-Control: no-store

Comment 2

[Charles C. Fu]

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

Comment 3

[Darin Fisher]

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.

Comment 4

[Charles C. Fu]

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

Comment 5

[Charles C. Fu]

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

Comment 6

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

> I don't know what component session history belongs to.

History: Session doesn't seem all that unlikely to me ;)

Comment 7

[Charles C. Fu]

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

Comment 8

[Darin Fisher]

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?

Comment 9

[Charles C. Fu]

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