currently, when the user presses the Back/Forward buttons, the page is loaded
using the load flag LOAD_FROM_CACHE. this causes necko to bypass any server
specified cache policy, and attempts to always take the page from the cache.
the page will only be loaded from the server if the cache does not contain the page.
in contrast, Netscape4x and IE will honor some of the server specified cache
policies when the user presses Back/Forward. for example, a page marked with
'Cache-control: no-cache' will be reloaded from the server when the user presses
Back under IE, but not under mozilla.
in effect, the distinction is between session history as a list of URLs or
session history as a complete historical view of what was previously viewed.
we've strived to provide the latter, but unfortunately it makes us inconsistent
with existing browsers and hence with content providers expectations.
the problem with mozilla's behavior is that many websites (online banks, webmail
apps, etc.) that enable the user to login and logout depend on the behavior of
Netscape4x and IE. they expect that after the user presses logout, that the
pages in session history (marked no-cache) will be fetched from the server when
requested via the Back button. this allows such web apps the ability to prompt
the user to login again. in mozilla, however, the web app is not contacted
again, and so even after the user has supposedly logged out, they are still able
to press Back to see their checking account statements again, for example. this
is a really big problem, IMO.
mozilla acts like IE only when the server sends 'Cache-control: no-store'
because this directive tells mozilla to not put the page in the cache. this has
the unforunate side effect of making view->source and file->saveAs require
server hits. so, IMO encouraging web apps to send 'Cache-control: no-store' is
not a good idea.
nominating for nsbranch
Created attachment 50981 [details] [diff] [review]
Comment on attachment 50981 [details] [diff] [review]
this has been a common issue and has manifested itself in several of our
cache/history related bugs. This is a "good to have" for the branch.
Comment on attachment 50981 [details] [diff] [review]
-> 0.9.4 branch
What's the problem that's being "corrected" here?
History navigation shouldn't touch the server (unless required by a page not
being in local storage at all, when the user should be warned and a fetch
It's part of the HTTP spec.
13.13 History Lists
User agents often have history mechanisms, such as "Back" buttons and
history lists, which can be used to redisplay an entity retrieved
earlier in a session.
History mechanisms and caches are different. In particular history
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
By default, an expiration time does not apply to history mechanisms.
If the entity is still in storage, a history mechanism SHOULD display
it even if the entity has expired, unless the user has specifically
configured the agent to refresh expired history documents.
This is not to be construed to prohibit the history mechanism from
telling the user that a view might be stale.
Note: if history list mechanisms unnecessarily prevent users from
viewing stale resources, this will tend to force service authors
to avoid using HTTP expiration controls and cache controls when
they would otherwise like to. Service authors may consider it
important that users not be presented with error messages or
warning messages when they use navigation controls (such as BACK)
to view previously fetched resources. Even though sometimes such
resources ought not to cached, or ought to expire quickly, user
interface considerations may force service authors to resort to
other means of preventing caching (e.g. "once-only" URLs) in order
not to suffer the effects of improperly functioning history
Opera have got this right I think and it (in part) adds to the speedy feel of
the app by enabling you to go backwards and forwards quickly irrespective of any
dubious caching directives made on the server to generate page hits.
check it in - PDT+
Darin - Let's add a list of sites to test, after this patch lands (i.e. banking
sites, calendars, and toher web apps).
i talked at lenght over irc last night with paulm... hopefully, i cleared up the
issues here :)
I appreciated Darin explaining things to me in IRC. However, it still seems to
me we are doing the wrong thing by moving away from what the HTTP spec suggests.
As I understand from chatting this fix is supposed to fix the fact that some
webapps are locking Mozilla out because of it's current behavior, not liking
that people can go back to pages they have seen after logging out for example.
I'd suggest that an appropriate fix to this would be evang, getting such apps to
use no-store rather than no-cache as that is what they should be using.
The use of no-store may cause problems with view-source/printing but that is a
seperate Mozilla bug (the _current_ page should be available in memory for such
OTOH I understand that this may be an appropriate quick fix for immediate
problems that would require a lot of work (evang and upgrading the
cache/history/view-source/printing subsystems) that may not be solvable in a
reasonable time. If so I think a bug should be filed on undoing this change,
dependant on other bugs involving those subsystems. Does that sound like a
I am a mozilla user who is very unhappy to see this change in 0.9.5. I
wrote a post to that effect at
http://www.mozillazine.org/talkback.html?article=2054&message=75#75, which I
will not repeat here. I also point out the comments in bug 33269, which
support the position that users want back/forward to be fast.
I think the excerpt from the HTTP spec captures the desired behavior
precisely, and am surprised to see it (apparently) casually ignored. Note
it is clear from the spec that back should not reload regardless of
cache-control attributes (even no-store): "History mechanisms and caches are
I am especially surprised to see this change made for the sake of web
authors who want to subvert traditional browser functionality. The
explanation in the original report ("this allows such web apps the ability
to prompt the user to login again") makes little sense, because the app can
still prompt the user to login again the next time he clicks. There is a
security concern (users leaving sensitive information in their history), but
breaking the browser is a poor way to handle it.
Remember: you can't change history. ;-)
actually, this change makes us more like existing browsers... and that is
exactly the reason why it was done. the HTTP/1.1 spec makes a suggestion about
what would be nice to have.... however, it does not require this. so, we
started out trying to do what the spec suggests, and found that we were
deviating from the normal browser behavior w.r.t. back/forward. compare mozilla
today to Netscape4.x or IE, and you will see that we behave similarly w.r.t. to
Darin, I understand your position. But you are holding up consistency with
other browsers and the interests of some web developers (whose argument I, a
web developer, find dubious), against the standard (granted, only a SHOULD),
the interests of users, and traditional functionality. It just seems poorly
I say the interests of users, because 1) I am convinced that users want a
fast back (as cited previously), 2) reloading eliminates the ability to see
an old page unchanged, even for a sophisticated user who knows that's what
he wants, and 3) the principle of least surprise: "history" implies static,
"back" implies what I was previously seeing.
I say traditional functionality, despite the fact that some browsers behave
differently, because the motivation for the change seems to be to allow not
only refreshing an old page, but also showing something entirely different
(eg, a login screen). This is just not what back was meant to do.
FWIW, here's a practical example of lossage. I'm reading a discussion on
slashdot, and follow a link. When I go back, mozilla attempts to put me in the
same place as before. But because the page was reloaded, the scores have
changed and the posts are in a different order, so where I end up is basically
random. Further, some posts I haven't read might have moved up, so I have to
read the whole page again to avoid missing anything.
i think you are assuming that this change effects the back behavior in all
cases, which is not true. we will only validate cached content on back when the
server sent the response using a restrictive cache control HTTP header (such as
'Cache-control: no-cache'). if you notice, this does not apply to many
dynamically generated websites, such as slashdot.
Only dynamic sites are likely to be using no-cache. (It makes no sense for static ones to do so). And as for Slashdot not using it, I guess you weren't logged in:
HTTP/1.0 200 OK
Date: Wed, 17 Oct 2001 01:16:49 GMT
Server: Apache/1.3.20 (Unix) mod_perl/1.25
X-Powered-By: Slash 2.001000
X-Fry: Leela, there's nothing wrong with anything.
X-Cache: MISS from cache.syd.integrity.net.au
X-Cache-Lookup: MISS from cache.syd.integrity.net.au:3128
Many other 'dynamic' sites use no-cache simply so more adverts are served.
I frankly don't give a crap what NS4 or IE do. Maintaining the status quo is a ridiculous argument. You don't compete with IE by trying to clone it, you compete with IE by being better than it. Ignoring cache-control directives on history navigation as the http spec suggests makes for a vastly improved user experience, it's that simple. Opera have it right and it's one of the factors that make it my primary browser when in Windows.
unfortunately, because of online banks which expect and require this behavior of
browsers, we have no choice but to either accept this reality or expect to be
blocked from many online banks, and all such banks have very little problem
blocking mozilla/netscape users on account of this issue. so, the "best" option
in my mind would be something like the addition of a pref that allows
back/forward to always pull from cache. it is unlikely that this pref would
ever be enabled by default until mozilla truly has a "kiosk mode."
A pref on this would certainly be a significant improvement.
A possible tweak to this would be to differentiate between http and https
connections and have a pref for each. Let the banks have their way with the
default setting for https and the user have their way for http. It's a tad
crufty but I think it'd mean everyone would be happy. The user would have a
snappier browser for 99% of their browsing and the banks would have something
that fits in with their current (misguided) ideas.
Ultimately I'd prefer such problems with banks to be solved with evang (banks
should be using no-store if they aren't already and their app should be handling
what happens with outdated pages, you can't trust a client anyway) but I can see
that some pragmatism is needed.
>unfortunately, because of online banks which expect and require this behavior of
This new change may create a false sense of security. Are we no longer cacheing
"no-cache" pages or just disabling the UI for retrieving them? If it is the
latter then I hope my bank uses "no-store" because there are numerous mechanisms
for retrieving this information from the cache outside of Mozilla.
Once upon a time I had to close my browser window to ensure removing sensitive
information from session history. My bank even closed the window for me when I
clicked "logout". I think that is the correct behavior according to the RFC and
is what most users would prefer. Site providers should let users know what to
expect and instruct them to end the session for security reasons. In the
interim lets give it a pref so people can choose.
we should carry this discussion forward on a new bug.
verified on branch:
Linux rh6 2001-10-22-17-0.9.4
Mac osX 2001-10-22-18-0.9.4
"Fixing" this bug caused bug 105395, "Moving back in history doesn't remember
scroll position sometimes".
The behavour caused by this patch (which was rushed through in 90 minutes) is
broken by design. See bug 112564 for backing this out.
(In reply to comment 24)
> (which was rushed through in 90 minutes)
Rushed through in 90 minutes, and surviving almost ten years of complaints and criticism. Congratulations, Mr Fisher!