User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913 Firefox/0.10 MSIE reloads a page marked as "no-cache" when a Back button is clicked, Firefox does not. See http://bugzilla.mozilla.org/show_bug.cgi?id=139541 for discussion. I would like to have the following options: * At the very least I would like to be notified (on the status bar maybe?) that the page I am viewing is stale. * I would like to have a setting which would allow Firefox to intervene when a stale HTML FORM is submitted, and to notify a user about that fact. * I would like a setting for "no-cache" pages to behave like "no-store" pages, that is, to be reloaded when a user goes back in history. It should be turned on on Windows for compatibility with MSIE. Reproducible: Always Steps to Reproduce: 1. Find any website with HTTP FORM and _no_ SSL. 2. Submit the FORM 3. Go back, you will see the same form with the same data, Firefox does not make an attempt to reload it. The behavior conforms to HTTP 1.1 specs but MSIE and older Netscape versions behave differently. Actual Results: Page is not reloaded Expected Results: Page is reloaded
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
Component: History: Session → Document Navigation
QA Contact: history.session → docshell
This is a more general issue, than form data. Pages flagged in the header as no-cache are not reloaded when viewed again using the back button. This causes security issues on public access terminals, as anybody can walk up to an open browser, use the back button and access (somebody else's) previously viewed 'secure' pages. NOTE, advising that people 'close the browser when they are done' is not an option, since some public libraries disable that ability.
> Pages flagged in the header as no-cache are not reloaded when viewed again > using the back button. That's the behavior the HTTP RFC requires, yes.
Where is that in the RFC? NOT reloading non-cached pages makes that functionality completely useless, since it would _always_ reload the page then.
Just to clarify, here is the HTTP response header being sent. FireFox is not re-requesting the page, when viewed using the Back button. This is not a secure connection. Content-Type: text/html; charset=UTF-8 Pragma: no-cache Expires: 0 Cache-Control: no-cache
RFC 2616 section 13.13. See also the last paragraph of same RFC section 13.2.1 and the last paragraph of section 14.9.2. We in fact to not make use of that MAY, for exactly the reasons you cite; thus no-store is available as an option for not allowing retrieval via history. This bug is about making no-cache behave exactly like no-store does. However the RFC is clear that no-cache is meant to apply to caches and that history mechanisms are not a cache in the HTTP worldview.
I believe that all browsers are now working consistently here, at least in the no-SSL case, and in fact we have many more requests to change our SSL behavior to match our non-SSL behavior due to the poor UX it has. So, I am closing this as WONTFIX. Feel free to open if there is something I am overlooking.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.