Title	SSL and IE no-cache bug
Date	06-May-2005 05:52:33 EEST
Version	JSPWiki v2.2.7-beta
Submitter	151.199.35.219
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):

     <user-data-constraint>
           <transport-guarantee>CONFIDENTIAL</transport-guarantee>
     </user-data-constraint>

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.

---------------------------

OK

---------------------------

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);
                     res.addDateHeader("Last-Modified",att.getLastModified().getTime());
 
+                    //
+                    //  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: http://www.mail-archive.com/tomcat-user@jakarta.apache.org/msg151294.html

   <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
       disableProxyCaching="false" />

---

Closing...