From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 BuildID: 2002053012 dynamic rendered pages gets protocol wyciwyg so they is cached even if source come through https connection (if memory cache is full I supouse) Reproducible: Always Steps to Reproduce: 1.open any https page with dynamic scripts 2.close mozilla 3.see your cache
Status: UNCONFIRMED → NEW
Ever confirmed: true
Reassigning. Can we ensure that wyciwyg pages (created by document.write) obey the no-cache rules of the page that writes them?
Assignee: mstoltz → gordon
Component: Security: General → Networking: Cache
QA Contact: bsharma → tever
Hey Radha, is this your cache client storing this?
Does the secure page have a no-cache directive? Even if it did, cache will continue to store no-cache pages so that back/forward to these pages will continue to work. The only thing that is not done for secure,no-cache pages is that, their form element state (layout history) is not saved, so that if you go back/forward to them, text fields and selection boxes will not restore their previous values.
after i close mozilla in my cache stay couple files with <meta http-equiv="Pragma" content="no-cache"> directive. In header of this document isnt such directive(any of anti caching directives), only meta in head of page. back / forward button will not work either well (language code of page is not stored correctly, in multi frame page back button will back frames in very cofusing way, links to images broken etc.), may wyciwyg free some memory consumation, but IMHO this protocol is useless.
the problem here is that the wyciwyg data is being stored in the disk cache instead of the memory cache. the wyciwyg implementation needs to use the same cache policy as the underlying channel. -> me
Assignee: gordon → darin
this has minor security implications since our policy for HTTPS content is not to store it in the disk cache. however, this is not a huge security problem IMO.
Severity: normal → major
Priority: -- → P2
Summary: https page is cached → https wyciwyg page is cached
Target Milestone: --- → mozilla1.2beta
i looked at trying to learn the security state of the main document channel, but after spending some time looking through nsHTMLDocument, it isn't obvious to me how to determine the channel used to load the original document. so, that leads me to consider the simpler solution of just always caching wyciwyg data in the memory cache. how does that strike folks? certainly wyciwyg data is not valid after restarting the browser, so having it in the disk cache isn't that helpful. however, having it in the memory cache obviously means that it will be more likely to be evicted. but, fortunately wyciwyg data is typically small, so such documents would be less likely to be evicted. thoughts? the best solution would still be to transfer the load flags from the original channel to the wyciwyg channel and make the wyciwyg channel honor the INHIBIT_PERSISTENT_CACHING load flag.
Created attachment 102264 [details] [diff] [review] v1 patch - stop gap measure this patch is a stop gap solution. it simply prevents wyciwyg data from being stored on disk. not optimal for the reasons i gave above, but should be sufficient. if we can't do better soon, then i think we should run with this for moz 1.2.
Created attachment 102271 [details] [diff] [review] v2 patch - potentially better solution of course, just after submitting the v1 patch i thought up a way to solve this. basically, all we have to do is record the load flags whenever we record the channel's principal. nsDocument::Reset is where the principal is recorded, so i added code to record the load flags there. as a result, nsHTMLDocument can easily apply those load flags to the newly created nsWyciwygChannel. this gives the nsWyciwygChannel context enough (by checking for the INHIBIT_PERSISTENT_CACHING load flag) to determine whether to use the disk cache or the memory cache. of course, i'm new to nsDocument and friends, so i half expect to hear that there is yet another better way.
Comment on attachment 102264 [details] [diff] [review] v1 patch - stop gap measure r=gordon for the v1 patch.
Attachment #102264 - Flags: review+
Want this in Blackbird I think
Comment on attachment 102271 [details] [diff] [review] v2 patch - potentially better solution r=mstoltz.
Attachment #102271 - Flags: review+
Comment on attachment 102271 [details] [diff] [review] v2 patch - potentially better solution email@example.com
Attachment #102271 - Flags: superreview+
Comment on attachment 102264 [details] [diff] [review] v1 patch - stop gap measure marking this patch obsolete. in addition to the reviews from rick and mitch, i've also bounced the second patch off of jkeiser, radha, and vidur.
Attachment #102264 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Keywords: adt1.0.2, nsbeta1, topembed
Comment on attachment 102271 [details] [diff] [review] v2 patch - potentially better solution a=asa for checkin to 1.2beta (on behalf of drivers)
Attachment #102271 - Flags: approval+
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
firstname.lastname@example.org for 1.0 branch; change mozilla1.0.2+ to fixed1.0.2 when checked in
Keywords: mozilla1.0.2 → mozilla1.0.2+
adt+ approval for the 1.0 branch
Keywords: adt1.0.2 → adt1.0.2+
Keywords: mozilla1.0.2+ → fixed1.0.2
verified trunk - 10/23/02 builds - linux rh6, mac osX, winNT4 still need to test branch
Status: RESOLVED → VERIFIED
Whiteboard: verified trunk
verified 1.0.2 branch - page sent via https not stored in disk cache anymore winNT4, linux rh6, mac osX 10/25/02 br
Keywords: fixed1.0.2 → verified1.0.2
You need to log in before you can comment on or make changes to this bug.