TitleSSL and IE no-cache bug
Date06-May-2005 05:52:33 EEST
VersionJSPWiki v2.2.7-beta
Submitter151.199.35.219
Bug criticalityLightBug (workaround exists, below)
Browser versionIE 6.0.2900.2180.xpsp_sp2_rtm.040803-2158
Bug statusClosedBug
PageProvider usedFileSystemProvider
Servlet ContainerApache Tomcat/5.0.28
Operating System2.4.21-20.EL (RHEL3)
URLsorry, no outside link available
Java version1.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...


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, 02-Dec-2008 00:18

Add new attachment

Only authorized users are allowed to upload new attachments.
« This page (revision-19) was last changed on 02-Dec-2008 00:18 by Keith Mashinter