Closed
Bug 261312
Opened 20 years ago
Closed 9 years ago
Cache-control: no-store should not affect session history navigation (when memory cache is large enough)
Categories
(Core :: Networking: Cache, enhancement)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: thebitman, Assigned: darin.moz)
References
(Blocks 1 open bug)
Details
(Keywords: perf, ux-control, ux-trust, Whiteboard: [dinosaurs])
Attachments
(1 file)
1.27 KB,
patch
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040803 Firefox/0.8
There should be an option or meta-key modifier for the back button which would
cause the page to load from cache only- no requests should be sent to the
server. ie: A way of truely going "back" to wherever you were before, exactly as
it looked before, with zero network activity/refreshing even on pages which have
cache options such as no-cache or an expiration date in the past.
The second part of this (and probably the more important), an option on the
POSTDATA warning dialog in addition to 'yes, resend the post data' and 'no, do
nothing', a third 'do not send the post data, view cached document' option would
be ideal.
Reproducible: Always
Steps to Reproduce:
1.
2.
3.
Comment 1•20 years ago
|
||
When hitting back results in loading the page from the server, that's because
Firefox no longer has a copy of the page in its cache. If there were a way to
hit back and still see the page, that would amount to not supporting the
cache-control: no-store header. Firefox supports no-store because of blackmail
from banks.
When hitting back results in a POSTDATA warning, that's because Firefox no
longer has a copy of the page. If Firefox had a cached copy, it wouldn't
display the POSTDATA warning when you hit the back button.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 2•20 years ago
|
||
While I agree that supporting cache-control headers is important, I still think
this warrants further discussion as this enhancement request was not meant as a
request to _remove_ support for anything- merely to add Options which would
allow one to change the way that support is implimented.
From a banking perspective, encouraging people to re-send postdata sounds more
dangerous than loading a cached page. Actually, online transactions was exactly
why I submitted this request- hitting the back button in order to get a
confirmation number without re-sending my shopping cart (which could lead to the
unlikely re-ordering of something, or the more likely giving me an error and
getting me absolutely nowhere)
A key thing to consider might be "Warning: Re-submitting from a cached page.
This is a bad idea. Are you absolutely sure?" (or simply disabling submit buttons)
If there were bugs previously filed and resulting discussion regarding this, I
couldnt find it before I submitted the request- a link to any you know of would
be appreciated.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 3•20 years ago
|
||
If I read Jesse's comment correctly, the page is NOT in cache at all. So, how do
you expect it to be shown if it's simply not there. Warnings or not, if
something is not in the cache, it will not be shown from the cache...
Comment 4•20 years ago
|
||
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2 says no-store
is intended to keep data out of non-volatile storage, and that it's OK for
no-store to not affect history navigation.
Changing summary from
option or meta-key for cache-only back button / POSTDATA warning
to
Cache-control: no-store should not affect session history navigation (when
memory cache is large enough)
Assignee: aaronleventhal → darin
Status: UNCONFIRMED → NEW
Component: Accessibility → Networking: Cache
Ever confirmed: true
Product: Firefox → Browser
QA Contact: bugzilla → core.networking.cache
Summary: option or meta-key for cache-only back button / POSTDATA warning → Cache-control: no-store should not affect session history navigation (when memory cache is large enough)
Version: unspecified → Trunk
Comment 5•20 years ago
|
||
OK I don't want to be evil, but that document also says that browser "MUST make
a best-effort attempt to remove the information from volatile storage as
promptly as possible".
I like this enhancement so I say no more ;)
Comment 6•20 years ago
|
||
On the other hand, it says "History buffers MAY store such responses as part of
their normal operation."
Assignee | ||
Comment 7•20 years ago
|
||
sorry, WONTFIX. making 'no-store' content appear to expire from the cache when
the user presses back (or forward) is a requirement of defacto web standards.
(as is doing the same for 'no-cache' content served over SSL.)
fwiw, we do keep 'no-store' content in the memory cache until it is expired via
LRU eviction, but we don't show it on back/forward because that is the behavior
that many web apps expect. we keep 'no-store' content in the cache so that
users can save it to disk if they choose, view the source of the page, or print
the content (in the case of images), etc. but, for session history navigation a
server hit is required. we also do not send an if-modified-since request when
validating 'no-store' content in the cache because we are not supposed to have a
copy of it from a HTTP point-of-view.
see bug 112564 for more info and many arguments on this topic.
this could be viewed as a battle between empowering users and empowering webapps
to protect their users. mozilla would simply be blackmarked as a non-compliant
web browser by many large enterprises including important ecommerce and ebanking
sites if we 'fixed' this bug.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → WONTFIX
V/wontfix.
Status: RESOLVED → VERIFIED
QA Contact: core.networking.cache → benc
Comment 9•13 years ago
|
||
[This was originally posted to one of the many other bug reports about this issue.
According to a friendly hint by Jesse Ruderman (bug 567365 comment #29), it appears that it really belongs in this bug report here. So I'm reposting it here.]
This patch fixes the issue by removing the offending test.
Additionally, the patch shows that Firefox does actually still have a copy of the page when it happens, as this code is invoked at the time when the page is shown, rather than at the time when to decide whether to keep it in the cache or not.
Similarly, File->WorkOffline also demonstrates that the page is really still cached.
Comment 10•13 years ago
|
||
Still broken in 7.0.1
Comment 11•11 years ago
|
||
I believe that, although WONTFIX may have been appropriate 10 years ago, it no longer is. This bug (and the many related bugs caused by this) is, in my view, a primary reason why many have jumped ship to Chrome/Safari. We used to recommend FF to all our clients and customers - but now we recommend against it. Why? The WONTFIX of 261312.
In fairness, we are more often seeing an uptake of ajax posts, which in many ways obviates the need to go back to the previous page after a secure post. However, for those apps that do use a page post, the problems that 261312 are manifold. This, I believe, is primarily due to sloppy web application code. For example - progressive (multi-page) forms sometimes set state on load, and this means that if someone wishes to use the back button to visit their previous submission, they have inadvertently affected the server-state for their submission.
Browsers are expected to be robust and forgiving. Not only for the users, but also for the developers - the complexity of being able to have a guess at the poor efforts of markup that are on the 'net continually amazes me.
The 'banks' issue is clearly a dead one. Webkit now accounts for 60% of the market, and this is one bug that they fixed a long time ago; the banks have all changed since 2008 - and their understanding of the 'net has radically changed over the last decade.
Let's not be dinosaurs.
Updated•11 years ago
|
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [dinosaurs]
Comment 12•11 years ago
|
||
Ben, thanks for your comment. I did not know that only reason for WONTFIXing this was long-obsolete.
Comment 13•11 years ago
|
||
The patch in bug 567365 fixes this bug. Is it just waiting for secreview?
Comment 14•9 years ago
|
||
I plan to take the no-cache version of this bug, but not the no-store one (this). Chrome, and I believe i.e., force network loads for no-store but not no-cache - so for compat sake we'll stay the same there.
Status: REOPENED → RESOLVED
Closed: 20 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•