|Title|Using SSL with Microsoft Internet Explorer V6 Spoils Preview Function
|Date|14-Nov-2004 16:58:54 EET
|Version|JSPWiki v2.0.52
|Submitter|[Lance D Bader|ldbader]
|[PageProvider] used|VersioningFileProvider
|Criticality|MediumBug
|Servlet Container|Tomcat 5.0.19
|Browser version|Internet Explorer 6.0 SP1
|URL|
|Status|ClosedBug
|Java version|1.4.1 IBM Build cn141-20030516

I decided to report this as a bug, but I will most likely move it to the [JSPWikiBrowserCompatibility] after it is reviewed.  I'm hoping that I've done something to cause the problem and it is not a compatibility problem after all.

My sites contain sensitive data that must be protected from corruption and observation while it is in flight.  To that end, I 
1ff8
have enabled SSL with a self signed certificate and configured a ''<security-constraint>'' element to guarantee confidential transport.

The problem can be demonstrated with Internet Explorer V6.
#Browse a wiki page
#Edit that page
#Preview your changes
#Press the back button to return to the edit page.

At this point all your changes will be lost.  Perhaps the Internet Explorer is refreshing the edit page incorrectly.  Mozilla Firefox does not have this problem.

I have used the following ''<security-constraint>'' element to demonstrate this problem.
{{{
<security-constraint>
    <web-resource-collection>
        <web-resource-name>
            BaderWiki
        </web-resource-name>
        <url-pattern>
            *
        </url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>
            CONFIDENTIAL
        </transport-guarantee>
    </user-data-constraint>
</security-constraint>
}}}

[Lance D Bader|ldbader]

''Ngh.  I thought we already solved the IE preview problems.  The problem is that IE refreshes its cache in some really strange manner, and I've never really figured out how and why. --JanneJalkanen''

Ah, the preview function relies on the cache!  That makes me nervous.  I don't think I will be using the preview function anymore, certainly not after typing more than a sentence.  

In any case, I think this is more subtle.  I don't think the page is ever written into the cache.  I think the biggest clue will be in the HTTP header. It seems to me that there is some way to have IE show the HTTP header of the current page, but I have forgotten how to do it.  Can anyone remind me?  Its not in the on-line help and a google search did not reveal anything.

I have always had the superstitious (in other words, without adequate proof) belief that the ''Check for newer versions of stored pages: Automatically'' option will cause a constant refresh when a page changes frequently.  Nothing changes more than the Edit.jsp page.  The documentation claims that it is only looking for images that change frequently, but I don't buy it.  I will run a test on a workstation where IE has never been used to edit a wiki page (assuming I can find one) and see if it fails the same way.
--[Lance D Bader|ldbader]

As Microsoft states in its [KB article|http://support.microsoft.com/default.aspx?scid=kb;en-us;174550], the form is repopulated only if the following items are true:
*The Web page is not an HTTPS (or secure) Web page.  
*The page is cached to disk.  
*The page has not changed since you filled out the form.
and most important __This behavior is by design__, so if IE decides to fill its cache with something it finds more important, then you cant do anything to force it to repopulate the form data.\\
Just a thought: Maybe that's why wikipedia.org always appends filled textarea to preview page.\\
--MinusDee

---
Hello

I have the same problem with Mozilla Firefox 1.0.1 on Mandrake 10.1 and JSPWiki configured on HTTPS.

But it works fine with konqueror 3.3.1

Xavier from ObjectWeb : https://wiki.objectweb.org

----

Hm.  So the right answer would not be to rely on the cache anymore, but to do a POST back to the Edit.jsp and repopulate the form with edited content.  I'll think about this, but it will make it a bit more difficult to do your own custom editors :-/

-- JanneJalkanen

----

This should be fixed in 2.2.8.   Please test.