|Title|SSL and IE no-cache bug
|Date|06-May-2005 05:52:33 EEST
|Version|JSPWiki v2.2.7-beta
|[Bug criticality]|LightBug (workaround exists, below)
|Browser version|IE 6.0.2900.2180.xpsp_sp2_rtm.040803-2158
|[Bug status]|ClosedBug
|[PageProvider] used|FileSystemProvider
|Servlet Container|Apache Tomcat/5.0.28
|Operating System|2.4.21-20.EL  (RHEL3)
|URL|sorry, no outside link available
|Java version|1.4.2_05-b04

Anytime you use SSL, you cannot download attachments in IE.

This is similar to a no-cache bug we ran into when downloading
files in IE after any authentication is added to 'security constraints'.
Put this in your security contraints in web.xml to get port 80 to forward
to 443 (default SSL):
This is a showstopper for my project.  I must be able to use SSL.
If you are not using SSL, you can get it to happen too, if you 
copy a full URL path of an attachment and *paste it into the address bar*.
and hit return.  (worst case scenario is *.xls files, which it looks like it is corrupting.)

The affect is that the attachment looks like its starting to load, and then it says:  
;:Microsoft Internet Explorer
;:Internet Explorer cannot download patches.xls from w3km.lexma.ibm.com.
;:Internet Explorer was not able to open this Internet site.  The requested site is either unavailable or ;:cannot be found.  Please try again later.

Both Apache and JSPWiki are putting no-cache in the header, which (as I'm told)
has the affect of loading the attachment and then immediately obsoleting it.

In FireFox this works fine. (but I'm told that's because firefox has a bug)

Since most users (here) use IE, this bug renders wikis to be fairly useless.
I can't download pages...

If anyone can look at this please reply back to me at [mailto:drrota@us.ibm.com] - thanks! ...Don...

more info here [http://lists.evolt.org/archive/Week-of-Mon-20011210/063326.html],
I tried changing the HTTP header to "Cache-control: no-cache, must-revalidate", and
"Cache-control: no-cache". Neither fixed the problem. When I changed it to "Cache-control:
must-revalidate", however, the problem downloading PDFs went away. 
[http://support.microsoft.com/default.aspx?scid=kb;EN-US;q297822] - 
{{{"RESOLUTION - If a document is intended to be viewed in this way, 
do not include any cache-control information with the HTTP headers."
"If the client communicates with the server over a secure connection
(https://) and the server returns a Pragma: no-cache header with the
response, Internet Explorer does not cache the response."
[http://servlets.com/rfcs/rfc2616-sec14.html#sec14.9.3] - 
{{{If a request includes the no-cache directive, it SHOULD NOT
include min-fresh, max-stale, or max-age."


Hmmm... Trying with my own SSL server (JSPWiki 2.2.12) and IE 6 (which I had to armwrestle from my girlfriend) everything seems to be working fine; attachments are properly downloaded.

Looking at the HTTP traffic (and code) JSPWiki is not sending back a Pragma: no-cache nor Cache-Control: no-cache, but they are done by the browser.

Try the following patch if it helps and let me know.  It should apply cleanly on 2.2.7 as well...
Index: com/ecyrd/jspwiki/attachment/AttachmentServlet.java
RCS file: /p/cvs/JSPWiki/src/com/ecyrd/jspwiki/attachment/AttachmentServlet.java,v
retrieving revision 1.29
diff -u -r1.29 AttachmentServlet.java
--- com/ecyrd/jspwiki/attachment/AttachmentServlet.java	5 Apr 2005 07:06:11 -0000	1.29
+++ com/ecyrd/jspwiki/attachment/AttachmentServlet.java	6 May 2005 08:25:20 -0000
@@ -197,6 +197,17 @@
                     // res.addDateHeader("Expires",expires);
+                    //
+                    //  Try to work around an IE bug...
+                    //
+                    if( req.isSecure() )
+                    {
+                        res.addHeader("Pragma", "no-cache");
+                        res.addHeader("Expires", "-1");
+                        res.addHeader("Cache-Control", "no-cache");
+                    }
                     // If a size is provided by the provider, report it.
                     if( att.getSize() >= 0 )


-- JanneJalkanen

I wish I had an environment to build it in, or knew where to put your patch.  What version 
of tomcat are you using?  Maybe my problem is with Tomcat and not JSPWiki - or perhaps
a combination of both.  Thanks for your help!  drrota@us.ibm.com

I'm using 5.0.28.  Drop me some email, I'll send you an updated .jar (if you can accept large mails). --JanneJalkanen


Janne, thanks for you help!  After searching for a solution (for a few weeks), I finally found it,
it was tomcat, not JSPWiki - I installed the latest version of tomcat and jspwiki and I still had the same
problem until I found this:
   <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
       disableProxyCaching="false" />




The proper solution to IE cache issues is to declare the attachment as "Pragma: private" and "Cache-Control: private, must-revalidate" in the HTTP Response.  This allows MS-IE to save the content as a temporary file in its local cache, but in not general public cache servers, before handing it off the plugin, e.g. Adobe Acrobat, to handle it.  Here is a code snippet as an example from the AttachmentServlet.java.

public void doGet( ... ) {


    // If a size is provided by the provider, report it.
    if( att.getSize() >= 0 )
        // log.info("size:"+att.getSize());
        res.setContentLength( (int)att.getSize() );

    // KM: Allow this to be put in a private, client-only cache to solve MS-IE issues.
    res.setHeader("Pragma", "private");
    res.setHeader("Cache-Control", "private, must-revalidate");

--[Keith Mashinter|mailto:kmashint@yahoo.com], 02-Dec-2008 00:18