Closed Bug 104162 Opened 23 years ago Closed 23 years ago

META http-equiv for Pragma, Cache-Control with content no-cache, no-store should remove Session History

Categories

(Core :: DOM: Navigation, defect)

Product:
Core
Component:
DOM: Navigation
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.1alpha

People

(Reporter: arun, Assigned: radha)

Details

This bug continues where bug 90288 left off. We should remove Form Values from Session History when no-cache for Pragma is detected, or when no-store for Cache-Control is detected. Form values should not be stored at all. I'm talking now about extending the functionalities of the http-equiv attributes to the META tag. A simple example is: <HTML> <head> <META http-equiv="Cache-Control" content="no-store"> </head> <BODY> <FORM name="myForm" id="form" METHOD="Post" ACTION="http://mombo.mcom.com:8043/cgi-bin/post-query.cgi"> <input type="TEXT" name="TEXT"></input><br/> <input type="TEXT" name="Text2"></input><br/> <input type="TEXT" name="Text3"></input><br/> <INPUT TYPE="Submit" Name="Submit" Value="SubmitThis"></INPUT> </FORM> </BODY> </HTML> Clicking "Back" should yield a fresh form. Substitute Pragma: no-cache if need be -- this is probably preferred by developers.
CC'ing Darin ...
Didn't we already have this discussion? See bug 93972, and bug 93027, among others. To summarise what I thought was the case: If the data is in the cache (and no-cache does not mean that it isn't in the cache), then session history will reload non-password form elements unless the attribute autocomplete="off" is set on the <form> or one of its elements[*]. This matches IE's documentation on the autocomplete attribute. I wonder why that particular case doesn't work, though. I suppose that the meta header is sent to http after we've already loaded the document, and put it in the cache, so there is a cache entry. Do we doom it, but only after SH loads, or do we just never doom the entry in this case? Can we doom an entry part way through? [*] IIRC, in one of these cases we store the values, but just don't load them when we revisit the page. There is no observable difference between those two cases.
bbaetz, set autocomplete="off" on the latest 0.9.4+/0.9.5 builds for a form. Post it. Click back. Now do the same for IE 6. See any different? Communicator 4.x provided this same feature using Pragma: no-cache via META tag, not via headers (altho' that worked also). This bug is to see if we can offer parity -- we now have it for cache, but not SH.
I don't have ie6 to test. The expected mozilla behaviour is that we do not refill the form elements - see bug 93972. If this no longer works, then it is a regression. AIUI, ns4 didn't offer this as a feature; it was a side effect of just never storing the data in the cache in the first place.
In fact, using autocomplete="off" blows away all the form values in 0.9.4+ when clicking "Back" but NOT so in IE6 -- I should have made that clear. I don't know what this data means... either we go a step beyond IE6, or else, MS understands something different by autocomplete="off"
Probably a bit of both. Anyway, the meta tag for no-store not working is a bug (probably an http one). The fact that no-cache doesn't clear these was a design choice.
I believe this is where we handle http-equiv stuff these days http://lxr.mozilla.org/seamonkey/source/content/html/document/src/nsHTMLContentSink.cpp#4660 . It looks like we could hook in there, or better yet, it looks like these specific headers get passed down into necko's channel's, maybe we could twiddle SH down there.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
i don't think necko should talk to session history... instead, i think we really need some sort of HTTP-EQUIV notification system. other components such as cookies could take advantage of something like this as well. however, we probably need a simpler solution for the 0.9.4 branch.
I'm moving this out, until we decide what to do with pragma: nocache. I think some changes are expected in nsHTTPChannel.
Target Milestone: mozilla0.9.6 → mozilla1.1
See also bug '112564, <meta HTTP-EQUIV="Pragma" CONTENT="no-cache"> allows Back.' I'm confused about the summary. Is this bug asking for breaking session history caching altogether (hitting back wouldn't work while offline), or is it just for not caching/filling form values?
Arun, Darin, considering the recent changes in the cache behavior, does this still matter?
radha: this should be fixed now. marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.