IE file could not be written to the cache

Today we’ve received a strange bug.

In one of our projects we are using SSL to protect the pages and data and users download PDF application forms and then do something with them. The problem is - in IE under SSL the download link lead to the following error message from browser:

File could not be written to the cache

Having searched a little on the web I’ve found that this is a known issue of IE and microsoft even suggests a solution to it by changing some registry flag :) can you imagine offering your clients to change something in their registry? So I dug again and found that response contains the following headers: Cache-Control: no-cache and Pragma: no-cache, which I did not add anywhere in the code. These headers cause IE to go crazy.

Then I debugged Tomcat a little and found a very funny piece of code:

        // Make sure that constrained resources are not cached by web proxies
        // or browsers as caching can provide a security hole
        if (disableProxyCaching && 
            // FIXME: Disabled for Mozilla FORM support over SSL 
            // (improper caching issue)
            //!request.isSecure() &&
            !"POST".equalsIgnoreCase(request.getMethod())) {
            if (securePagesWithPragma) {
                // FIXME: These cause problems with downloading office docs
                // from IE under SSL and may not be needed for newer Mozilla
                // clients.
                response.setHeader("Pragma", "No-cache");
                response.setHeader("Cache-Control", "no-cache");
            } else {
                response.setHeader("Cache-Control", "private");
            }
            response.setHeader("Expires", DATE_ONE);
        }

especially funny are the FIXME lines in production code. All in all Tomcat is adding two extra lines to response headers which no-one has asked him to. So how do I fix that? The location of this code is in org.apache.catalina.authenticator.AuthenticatorBase, and the concrete class will depend on the type of authorization you’re using. We did not use JEE authorization so the class was org.apache.catalina.authenticator.NonLoginAuthenticator, this is an Authenticator and a Valve so it can be configured using context.xml. Add the following lines to your war’s context.xml:

<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator" securePagesWithPragma="false"/>

This is it :)

First published on the old anydoby.com blog on 2008-06-06.