Last Comment Bug 151478 - https wyciwyg page is cached
: https wyciwyg page is cached
Status: VERIFIED FIXED
verified trunk
: topembed
Product: Core
Classification: Components
Component: Networking: Cache (show other bugs)
: Trunk
: x86 Windows 2000
: P2 major (vote)
: mozilla1.2beta
Assigned To: Darin Fisher
: Tom Everingham
Mentors:
https://cowtools.mcom.com/bugs/151478...
Depends on:
Blocks: blackbird
  Show dependency treegraph
 
Reported: 2002-06-13 03:24 PDT by Zdenek Cerny
Modified: 2002-12-20 16:26 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
v1 patch - stop gap measure (740 bytes, patch)
2002-10-08 16:53 PDT, Darin Fisher
gordon: review+
Details | Diff | Review
v2 patch - potentially better solution (10.44 KB, patch)
2002-10-08 17:39 PDT, Darin Fisher
security-bugs: review+
rpotts: superreview+
asa: approval+
Details | Diff | Review

Description Zdenek Cerny 2002-06-13 03:24:44 PDT
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
Comment 1 John Morrison 2002-06-13 21:08:20 PDT
Yep.
Comment 2 Mitchell Stoltz (not reading bugmail) 2002-08-02 16:37:46 PDT
Reassigning. Can we ensure that wyciwyg pages (created by document.write) obey
the no-cache rules of the page that writes them?
Comment 3 gordon 2002-10-03 15:43:39 PDT
Hey Radha, is this your cache client storing this?
Comment 4 Radha on family leave (not reading bugmail) 2002-10-03 17:01:55 PDT
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. 
Comment 5 Zdenek Cerny 2002-10-04 01:41:36 PDT
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.
Comment 6 Darin Fisher 2002-10-04 10:16:50 PDT
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
Comment 7 Darin Fisher 2002-10-04 10:18:01 PDT
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.
Comment 8 Darin Fisher 2002-10-06 12:51:19 PDT
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.
Comment 9 Darin Fisher 2002-10-08 16:53:38 PDT
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.
Comment 10 Darin Fisher 2002-10-08 17:39:37 PDT
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 11 gordon 2002-10-08 18:12:42 PDT
Comment on attachment 102264 [details] [diff] [review]
v1 patch - stop gap measure

r=gordon for the v1 patch.
Comment 12 Daniel Veditz [:dveditz] 2002-10-08 22:58:13 PDT
Want this in Blackbird I think
Comment 13 Mitchell Stoltz (not reading bugmail) 2002-10-10 15:19:17 PDT
Comment on attachment 102271 [details] [diff] [review]
v2 patch - potentially better solution

r=mstoltz.
Comment 14 rpotts (gone) 2002-10-10 17:07:30 PDT
Comment on attachment 102271 [details] [diff] [review]
v2 patch - potentially better solution

sr=rpotts@netscape.com
Comment 15 Darin Fisher 2002-10-10 17:10:52 PDT
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.
Comment 16 Asa Dotzler [:asa] 2002-10-10 17:56:07 PDT
Comment on attachment 102271 [details] [diff] [review]
v2 patch - potentially better solution

a=asa for checkin to 1.2beta (on behalf of drivers)
Comment 17 Darin Fisher 2002-10-10 21:32:20 PDT
fixed-on-trunk
Comment 18 [:jesup] on pto until 2016/7/5 Randell Jesup 2002-10-14 13:56:22 PDT
a=rjesup@wgate.com for 1.0 branch; change mozilla1.0.2+ to fixed1.0.2 when
checked in
Comment 19 Daniel Veditz [:dveditz] 2002-10-16 14:49:26 PDT
adt+ approval for the 1.0 branch
Comment 20 Darin Fisher 2002-10-21 15:19:54 PDT
fixed1.0.2
Comment 21 Tom Everingham 2002-10-23 16:59:35 PDT
verified trunk - 10/23/02 builds - linux rh6, mac osX, winNT4

still need to test branch
Comment 22 Tom Everingham 2002-10-25 11:03:08 PDT
verified 1.0.2 branch - page sent via https not stored in disk cache anymore

winNT4, linux rh6, mac osX   10/25/02 br

Note You need to log in before you can comment on or make changes to this bug.