User-Agent: Mozilla/5.0 (Linux 2.4.20-grsec-1.9.8-rc1 i686; U) Opera 6.11 [en] Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130 The general problem is that Mozilla does not differentiate caching and history-list-for-back-button. Which means that pressing the back button will try to reload the page previously visited, almost as if it was entered into the url bar. This includes validating anything that may be found in the cache, and if the page has already expired, it is loaded again from the origin server. If the page was the result of a POST request, a pop-up dialog shown to let the user decide if he wants to resubmit the original form or cancel the whole operation. There's no provision to not resubmit it but still show the page. This is bad. First, it prevents me from viewing what I have seen previously. Second, it generates an enourmous superfluous traffic. Third, it's against standards: RFC2616 clearly states that "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 retrieved. 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 bug has existed at least since Netscape 4.0, if not even before. Reproducible: Always Steps to Reproduce: 1. open up Mozilla 1.2.1 2. enter "http://www.generali.hu/belso.php?tart=ecasco_2&menu=4&almenu=4&alalmenu=3" as the url 3. in the middle of the page choose "személygépjármû" and submit with "ok" 4. in the middle of the page, in the next field choose "ALFA ROMEO" and submit with "ok" 5. press Back Actual Results: you get a dialog saying "the page you are trying to view contains POSTDATA that has expired from cache. if you resend the data, any action the form carried out (such as a search or online purchase) will be repeated. to resend the data, click ok. otherwise, click cancel." clicking ok resubmits the form, clicking cancel will cancel the "back" operation Expected Results: First, the correct way is to show the previously seen contents. As seen previously. If it has expired, a dialog could be shown, which may remind me to reload/resubmit the page, but allowing me to view the old data. If such a dialog is implemented it should also be configurable away in Preferences (so that I don't have to always click 'No, don't reload' every time I use Back).

Is this being dealt with? I think it's a pretty major issue...

To me, this is probably the most annoying "feature" in Mozilla right now. It's a serious problem if you want to go back and double check something in an ecommerce sequence --- you end up with multiples of what you ordered that you have to remember to edit out before finishing the purchase. And just now, it hosed this very posting: I entered a new email address to be added to the CC list, not realizing it was going to verify it against the database of email addresses. It told me to use the Back button to correct it, but when I did, sure enough "your data has expired" and I had to start all over again because it redid the search for a matching bug.

I have to agree with the other posters, this is one serious bug that annoys the heck out of me. I was debugging an ASP.NET page today and set a breakpoint on the server-side code, not any javascript. Every time I went back to the page I noticed that the breakpoint was hit; which means that Mozilla wasn't accessing the cache it was resubmitting the request for the page. I set the cache option to "When the page is out of date" and "Once per Session" and neither one made a difference. The original poster indicated he was using Mozilla 1.2.1, but I'm using the latest beta, Mozilla 1.4b, and it still does this. It is a SERIOUS diffenciency in a browser to not be able to properly go back. Simply going back, or forward, should never re-request the page; that's what reloading is for.

I just discovered that if you *View Page Source* ?!? it reposts the data! And now that I think about it, something that's always been a minor source of annoyance is that printing pages refetches them too, which makes it really hard to capture something like an order you'd just submitted. I really hope this stuff isn't scattered throughout the code...

Still a problem in Mozilla 1.6 - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

Another example: I was sending a paypal payment, gathering a few part numbers from the payee's website to paste into the comment field. By the time I clicked the submit button, my session had "expired". I don't know if any javascript black magic was involved, but the back button refused to bring me back to the previous page without a reload, which got me directed to the login prompt instead of the payment form. My carefully prepared comment was therefore lost. The only recourse a user has is to copy all information from forms into a text editor before submitting, to guard against the possibility of session expiration. What a pain. I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0.

Some document I read recently, I think one on the W3C site, points out that intent is for browser back and forward buttons to re-display what the user saw before, not for them to (re-post and) re-retrieve data. Mozilla certainly should not issue a request to the server for back/forward, for printing, for Send Page, or for View Source. Those operations should operate on the already- retreived data. They should not make new HTTP requests.

Note bug 288462.

I work at a commerce payment company and my department trouble shoots commerce sites, and we constantly receive this little annoyance about post data and using the back button, would it be possible to make this warning optional by a setting or even an extension.

Shouldn't this have the "dataloss" keyword (which would imply it being critical)? Most of the other bugs tracked by bug 288462 do.

Comments seem to be conflating this with some combination of bug 288462 (don't reload without explicit request), bug 569142 (don't reload on history navigation), and/or bug 160144 (improve the lousy POSTDATA dialog that appears when reloading a POST result). For dependency with other bugs I'm going to treat it as the original description from comment 0, "The general problem is that Mozilla does not differentiate caching and history-list-for-back-button" (that's called "session history" in comments on other bugs), and use a short description like "clearly distinguish between history & cache." I'm not sold on the idea that everything should always be stored. I don't see cases where data should self-destruct, but I don't work with sensitive information (medical records, trade secrets, troop positions...). I agree that the headers to prevent history retention are overused, but I think it would be a mistake for the protocol to not have that feature (or, almost equivalently, for a browser to ignore that feature). Regardless of weather it's possible to exclude specific pages from history, there should certainly be a difference between the "history" (back/forward only) and "cache" (also used for new requests), and there should be more kept in history than cached - maybe the cache should be a subset of the history. Added blocks bug 569142 (don't reload on history navigation); this should also block bug 567365 (content of https with no-cache set is not retained for history), and bug 160144 (improve the lousy POSTDATA dialog that appears when reloading a POST result).

> I'm not sold on the idea that everything should always be stored. I don't see > cases where data should self-destruct, but I don't work with sensitive > information (medical records, trade secrets, troop positions...). The worst part is that the data actually doesn't even self-destruct, it is merely "well" hidden as shown by bug 567365 comment 15 . If the POSTDATA dialog pops up, just click cancel, then File->Work Offline, and then try back again. You now see the supposedly self-destructed page, which makes this misfeature unsuitable for security purposes. Of course, the annoyance factor is still there, as most users won't know this. > I agree that the headers to prevent history retention are overused Are there even any headers that are meant to prevent history retention? If so, which would these be, and which RFC would define those? As it is now, Firefox just creatively misunderstands some headers which mean something entirely else to prevent history retention. And other browsers (such as Internet Exploder) misunderstand a slightly different set of headers in a similar way. But (as far as I know), there are no RFC-defined headers which really mean "no history". Chrome uses the exact same set of headers as Firefox, but probably only because they copied the algorithm from Firefox. Opera, on the other hand, does the sane thing, and always keeps history. > it would be a mistake for the protocol to not have that feature So, propose an RFC, and submit it to the usual RFC process. Just misinterpreting unrelated headers for your purpose is a recipe for disaster. > (or, almost equivalently, for a browser to ignore that feature) Well, so far, a browser cannot ignore such a protocol feature, as the protocol doesn't have one yet (as far as I know... Feel free to quote RFCs that are evidence to the contrary) An the worst part is: Firefox *does* distinguish between history and cache, as witnessed by the difference in behaviour if Cache-Control: max-age=0,must-revalidate is set. A page with such control is refreshed when you revisit it by re-entering the URL, but not when going back in history. So on the lowest level, Firefox is quite capable to handle both situations differently. There is no technical reason for this misfeature, and the fix is to just remove the special case for Cache-Control: no-store and Cahce-Control: no-cache + SSL. The fix is literally an 11 line change, as posted in bug 160144 comment 186. And there is no security reason either, as this misfeature doesn't really protect anything (as seen by the "Work Offline" workaround above). So, did any banks blacklist Firefox since "Work Offline" existed? No! Did any banks blacklist Opera? No! So why keep sticking to this (IMHO broken) policy? If some people really feel strongly about keeping the current behaviour, at least give us an option to toggle this using an about:config option

After a little searching, I think the biggest cause of the problem is that RFC 2616, which defines HTTP/1.1, doesn't adequately describe how a history mechanism should behave. It seems to me that Firefox does not adequately distinguish the two, but rather behaves strangely when the conformant behavior is unclear - I expect the particularly bizarre case where cancel-offline-reload displays the retained data is an example of that. (I haven't seen where any RFC addresses offline mode at all.) I had the impression that "no-store" meant "don't store this," but after a little reading it's unfortunately not that simple. The RFC - http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2 - says a caching mechanism must never write to non-volatile storage at all, a caching mechanism must discarded from all storage immediately after display or transfer, a user agent must allow normal interaction (e.g. save as), and a history mechanism may store it. It is not clear on weather a history mechanism may store it to non-volatile storage. The interpretation that a history mechanism must discard it immediately (just like the cache) seems wrong, but the interpretation that a history mechanism must not write it to non-volatile storage seems both reasonable and useful. Unfortunately, the lack of a standard interpretation of how the history mechanism should behave makes it much less useful. Fixing bug 493438 (disclose why a page isn't stored in history) would be a big help for both users & site developers in understanding what's going on. I think, with respect to this bug, the important thing is to make there be exactly three cases for retention after navigating away from a page (the page should never leave volatile storage while current): 1) keep for cache & history, 2) keep for history only, 3) don't keep at all. The cancel-offline-reload case is none of these. What to do on no-store is (essentially) a choice between 2 and 3, and is out of scope here. When a cached page expires it should move from 1 to 2.

"It is not clear on weather a history mechanism may store it to non-volatile storage." Basically, it does not matter. The history mechanism can be memory-only, and then all these questions have no significance at all. This is actually what I'm interested in, anyway. There could be a configuration option (that is actually a feature) for those who want to store the history on disk as well, to survive browser restarts. Now in this case, the browser MIGHT honour this 'no-store' flag by default by not writing it to disk, but even then there SHOULD be a configuration option to override it. Anyway, the not-stored history entries should still be retained in memory, even when storage on disk is enabled. "When a cached page expires it should move from 1 to 2." You have the presumption that this "cache" & "history" are some kind of architecturally similar stores. I doubt that it's possible to implement it that way... The cache stores the source files only whereas for the history function to work as expected, you'd have to store the runtime status of the page (eg: javascript variables, form fields filled already, all the parts of the DOM that have been dynamically set up, etc.), which I don't think is easy if you try to approach that from a "source file cache" direction... But this is only an implementation question.

(In reply to comment #15) > "It is not clear on weather a history mechanism > may store it to non-volatile storage." > > Basically, it does not matter. The history mechanism can be memory-only, and > then all these questions have no significance at all. This is actually what I'm > interested in, anyway. My memory doesn't store anywhere near as much as my disk, and I'm usually using my memory for things that need to be more responsive than my browser history. I would not want the history mechanism to be memory-only. I would be fine with no-store pages being retained in memory until the point where other pages are moved to disk, and discarded at that point. > "When a > cached page expires it should move from 1 to 2." > > You have the presumption that this "cache" & "history" are some kind of > architecturally similar stores. I doubt that it's possible to implement it that > way... Right, they may be too different to actually move between. The important thing is that cache expiration removes a page from the cache but not from the history.

Still broken in 4.0.1