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)

x86
All
enhancement
Not set
normal

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)

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.
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
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 → ---
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...
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
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 ;)
On the other hand, it says "History buffers MAY store such responses as part of their normal operation."
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 ago20 years ago
Resolution: --- → WONTFIX
V/wontfix.
Status: RESOLVED → VERIFIED
QA Contact: core.networking.cache → benc
Blocks: 288462
[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.
Still broken in 7.0.1
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.
Status: VERIFIED → REOPENED
Resolution: WONTFIX → ---
Whiteboard: [dinosaurs]
Ben, thanks for your comment. I did not know that only reason for WONTFIXing this was long-obsolete.
The patch in bug 567365 fixes this bug. Is it just waiting for secreview?
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 ago9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: