Closed Bug 1349006 Opened 8 years ago Closed 8 years ago

Back button doesn't reload iframe from server if the GET responds depends on referrer but doesn't say so

Categories

(Core :: Networking: Cache, defect)

Product:
Core
Component:
Networking: Cache
Version:
52 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: sriveros, Unassigned)

Details

(Whiteboard: [parity-IE][parity-Edge])

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build ID: 20170316213829 Steps to reproduce: Suppose I am on the following page: http://www.smsequip.com/news-and-media/news The list is in an iFrame. When I click on a "Read more..." link, the page navigates to a specific news article via the id supplied by the query string ?news={id}. http://www.smsequip.com/news-and-media/news?news=41 However, when the back button on the browser is clicked and we navigate back to the previews page without the query string, the content on the page does not update to reflect the change in the URL. It works fine is all other browsers (IE, Chrome, Safari, etc...); however, not so for Firefox. Actual results: Back button is clicked, URL changes, but the page does not. Expected results: The page should show the content pertaining to the previous URL being displayed (history).
Summary: Back button no working for content in an iFrame → Back button not working for content in an iFrame
Edge38.14393.0.0 and IE11 works as expected. However, Google Chrome57.0.2987.98 is also same behavior of Firefox45esr and Nightly55.0a1. Seems, this is the site problem.
Component: Untriaged → Document Navigation
Product: Firefox → Core
Whiteboard: [parity-IE][parity-Edge]
No, it's a caching issue in Firefox and Chrome. I have submitted the same bug to Google yesterday and they have acknowledged that this is a bug and they will be working to fix it. Likewise, this bug has already been submitted to Mozilla 11 YEARS ago and still has not been fixed!!! Tisk, tisk, Mozilla! 38 members of stackoverflow agree that this is a Firefox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=356558 61 members of stackoverflow believe this is a caching issue in Firefox. http://stackoverflow.com/questions/2648053/preventing-iframe-caching-in-browser What a shame. 10 years is not enough to fix this? We desperately need a fix for this one.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
It's not clear to me based on the description that this is the same as the situation described in bug 356558. that bug is about loading a URL,like <http://www.smsequip.com/news-and-media/news>, the navigating some subframe of that page, then reloading the toplevel page and the new content from the server has a different URL for the iframe. And then the question is what should load in that iframe. I see no mention of reload anywhere in this bug, so I suspect this is a different issue. I should note that if instead of clicking the link I do the following steps: 1) Load http://www.smsequip.com/news-and-media/news 2) Load http://www.smsequip.com/news-and-media/news?news=41 3) Click back then everything works correctly. So there's something else interesting going on here... That said, even if I disable script following the steps to reproduce from comment 0 reproduces the bug, so it's not like the page is doing something weird with scripting. Olli, any idea what's going on here?
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: needinfo?(bugs)
Resolution: DUPLICATE → ---
The iframe URL http://www.smsequip.com/applications/news/en/index.php displays different content according to its referrer. During a page navigation, the referrer is changed and hence different content is served. According to Devtools, on navigation, Firefox directly pulls the page from the cache. I doubt Firefox would and should be aware the referrer change would cause a change in the content. The issue could likely be fixed by adding a Cache-Control:no-cache on http://www.smsequip.com/applications/news/en/index.php.
*According to Devtools, on back navigation, Firefox directly pulls the page from the (bf-)cache.
Ah, comment 5 explains what's going on. Given that, I suspect this is in fact not a bug: we're reading from our cache (not bfcache, fwiw) and there's no obvious reason we shouldn't be caching that page given the headers it sends. But over to necko to make that decision.
Component: Document Navigation → Networking: Cache
Flags: needinfo?(bugs) → needinfo?(honzab.moz)
Summary: Back button not working for content in an iFrame → Back button doesn't reload iframe from server if the GET responds depends on referrer but doesn't say so
According dev tools, response to http://www.smsequip.com/applications/news/en/index.php has Cache-control: private, no-cache, no-store, proxy-revalidate, no-transform. It either has changed the last day or comment 5 is mistaken. I can see a request being made to that URL on navigating back. I'm therefor not sure about the test case is still valid. Hard to decide. Closing for now.
Status: REOPENED → RESOLVED
Closed: 8 years ago → 8 years ago
Flags: needinfo?(honzab.moz)
Resolution: --- → INVALID
> It either has changed the last day or comment 5 is mistaken. It got changed. The behavior I was seeing is gone too...
Yes, the developer of https://www.smsequip.com has implemented the workaround found here: http://stackoverflow.com/questions/41546321/how-to-prevent-iframe-caching-in-chrome/42986623#42986623 Although not an ideal or the preferred solution (especially the extra bit of JavaScript required), and since Mozilla marked this bug (1349006) as a duplicate of bug 356558 (https://bugzilla.mozilla.org/show_bug.cgi?id=356558), which to this day remains unresolved for past 11 years, the developer decided it would be wise to improvise. Also, they are working on a refresh of the website. Which is more likely to be available prior to a resolution to this problem.
For what it's worth, this bug is not a duplicate of bug 356558 but was definitely a bug in the site: It was varying the response based on referrer, but not saying so in the response (not something you're allowed to do per the HTTP spec), so the browser thought it was fine to cache it. Had the site just sent "Vary: referrer", there would have been no problem.
(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #11) > For what it's worth, this bug is not a duplicate of bug 356558 but was > definitely a bug in the site: It was varying the response based on referrer, > but not saying so in the response (not something you're allowed to do per > the HTTP spec), so the browser thought it was fine to cache it. Had the > site just sent "Vary: referrer", there would have been no problem. I didn't mark this bug as duplicate of 356558: http://www.smsequip.com/images/duplicate-bug.jpg Also, your statement about using the Very header is not entirely accurate. I have tried your suggestion and it only worked for Chrome, but it still did not work for Firefox: http://www.smsequip.com/images/vary-referrer.jpg http://www.smsequip.com/images/vary-referrer-lowercase.jpg Just for kicks, I will leave the site broken for the next few hours so that you can see for yourself. I didn't need to do anything for IE or Edge and it works just as expected (which is odd as it is usually the other way around). Why is your browser making the assumption that I would like to cache the iFrame when I haven't explicitly ask? If anything the opposite assumption should have been made if such configurations are not present. I am actually more disappointed with Chrome (my favorite browser).
Thank you for putting this back into a state where the problem can be reproduced. Does it work as you expect if you do "Vary: referer"? I forgot that the HTTP spec mis-spells the header name.... > Why is your browser making the assumption that I would like to cache the iFrame when > I haven't explicitly ask? The HTTP spec says things can be cached unless they explicitly opt out. Otherwise nothing would ever be cacheable, pretty much, since most pages don't send any indications of whether to cache them or for how long. In the absence of any such indications, browsers are expected to cache, applying some heuristics to determine freshness lifetimes and whatnot.
(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #13) > Thank you for putting this back into a state where the problem can be > reproduced. Does it work as you expect if you do "Vary: referer"? I forgot > that the HTTP spec mis-spells the header name.... > > > Why is your browser making the assumption that I would like to cache the iFrame when > > I haven't explicitly ask? > > The HTTP spec says things can be cached unless they explicitly opt out. > Otherwise nothing would ever be cacheable, pretty much, since most pages > don't send any indications of whether to cache them or for how long. In the > absence of any such indications, browsers are expected to cache, applying > some heuristics to determine freshness lifetimes and whatnot. Yes, I read the specs. And sure, I agree with you that it can cache whatever it wants in the absence of any indications of whether it should cache. However, the specs also states that the history and cache mechanisms SHOULD NOT try to SHOW a semantically transparent view of the current state of a resource. Rather, a history mechanism is meant to SHOW EXACTLY what the user saw at the time when the resource was retrieved (13.13 History Lists). So, in essence, the user requests http://www.smsequip.com/news-and-media/news (cache 1), then navigate to http://www.smsequip.com/news-and-media/news?news=41 (cache 2), Back button pressed -> SHOW EXACTLY what user saw in http://www.smsequip.com/news-and-media/news (retrieve cache 1), Forward button -> SHOW EXACTLY what user saw prior to pressing the Back button, which is http://www.smsequip.com/news-and-media/news?news=41 (retrieve cache 2). Anyway, thanks for suggesting Vary: referer. It worked for both Firefox and Chrome. It's a lot better than using JavaScript as a workaround.
> However, the specs also states that the history and cache mechanisms SHOULD NOT > try to SHOW a semantically transparent view of the current state of a resource. That's true. In practice, we may no longer have the view of the resource that the user last saw available, and in that case we have no choice but to go ahead with an actual HTTP load. And since the HTTP cache is keyed on the URL, our only options are to load from there or load from the server, and in the latter case we'd need to know that we can't just use the cached thing... I'm glad to head that "Vary: referer" worked right. I was worried that it would be problematic too...
You need to log in before you can comment on or make changes to this bug.