259680 - Make a setting so pages with "no-cache" would behave the same as with "no-store"

Status: RESOLVED WONTFIX

(Core :: DOM: Navigation, enhancement)

Description

[Michael Jouravlev]

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

Comment 1

[Gervase Markham [:gerv]]

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/

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

.

Comment 3

[amy_eavan]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 5

[amy_eavan]

Where is that in the RFC?  NOT reloading non-cached pages makes that functionality completely useless, since it would _always_ reload the page then.

Comment 6

[amy_eavan]

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

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

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.