Bug 27122 - IE plugins cannot access components through Tomcat 5 over SSL
Summary: IE plugins cannot access components through Tomcat 5 over SSL
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Connector:HTTP (show other bugs)
Version: 5.0.18
Hardware: Sun Solaris
: P3 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
: 28662 29336 29975 30618 36735 (view as bug list)
Depends on:
Reported: 2004-02-20 21:09 UTC by Daniel Potter
Modified: 2011-05-22 22:55 UTC (History)
6 users (show)


Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Potter 2004-02-20 21:09:17 UTC
SSL seems to be failing when the Content-Type header is set to "image/svg+xml".

I've only seen this failure when SSL was running on a Solaris machine.  (uname
-a: SunOS [hostname removed] 5.8 Generic_108528-18 sun4u sparc SUNW,Ultra-60) 
When attempted on Windows, we were unable to duplicate the error.  This reliably
fails when attempted on this specific Solaris machine.  If I get a chance, I'll
try to create a test-case and see if I can reproduce this on other Solaris
machines.  Unfortunately, this was a show-stopper for a release that's being
made today so I'm pressed for time.

Basically, what happens is that we're using a JSP page to create an SVG file. 
Because of this, we have to set the Content-Type header to "image/svg+xml". 
When the MIME type is set to this value, the page fails to load in Internet
Explorer 6 (SP1) with a message of "connection failed" or something similar. 
When an attempt was made in Opera, Opera responded by crashing.  Mozilla
successfully downloaded the file, though.

However, when resetting the MIME type in the page to "text/plain" all three
browsers can access the page without failure.  By back-revving Tomcat to version
4.1.29, we were able to resolve this issue and access the page in all three

I'll try and create a test-case later today and verify that it isn't just our
SVG JSP that's failing but any that creates SVG but I'm currently pressed for
time - sorry.
Comment 1 Remy Maucherat 2004-02-20 21:14:26 UTC
How about trying with a telnet ? Either the content is sent or it is not.
There's nothing to investigate here, as there is nothing in Tomcat which is
related to the content-type, so I urge posting on tomcat-user instead.
Comment 2 Daniel Potter 2004-02-20 21:24:11 UTC
Of course I haven't tried telnet, it's only happening over SSL.  I'm not very
good at doing 128-bit encryption in my head and I doubt anyone else is either. 
If I could find something that would do SSL and dump the actual HTTP transaction
I would do that - I haven't yet (especially because form security is in place on
the webapp).

However, considering that it *only* failed with the latest Tomcat 5 and works
just fine in Tomcat 4 I find it hard to believe that there isn't something wrong
with Tomcat 5.  If it failed when back-revving the version, I might blame
something else.  But this is 100% reproducable among multiple clients and only
when connecting to the Tomcat 5 server using SSL.

This *only* fails when using SSL through Tomcat 5.  It works with Tomcat 4,
using the same JDK and the same configuration.  It also works in Tomcat 5 if I
use the standard HTTP connector.  I can't figure out how to begin to debug this,
but if anyone can offer any suggestions on utilities to debug SSL connections
I'll take a stab at it next week.
Comment 3 william.barker 2004-02-20 21:40:33 UTC
Try 'openssl s_client'.  It's my first stop when debugging SSL problems.
Comment 4 Remy Maucherat 2004-02-20 23:33:08 UTC
Well, I understand, but the behavior you describe would be extremely strange. I
don't see how it can be a Jasper or container issue, and I don't see how it can
be a connector issue either (the connector doesn't have content-type specific at
all either, except when HTTP compression is used). Tomcat 4.1.29 uses the same
connectors as 5.0.14, and similarly 4.1.30 uses the same as 5.0.18, so again I
don't understand a difference in behavior between the two "branches".
Comment 5 Daniel Potter 2004-02-25 21:50:01 UTC
OK, I finally got a chance to use "openssl" to try and manually run a couple of
HTTP transactions.  I found one header I thought may be a problem that's
included in Tomcat 5 but not Tomcat 4: "Expires: Wed, 31 Dec 1969 19:00:00 EST".
 Unfortunately, updating it to a more realistic "expires" date didn't allow IE
to work.

I'm as stumped as everyone else is as to what might be causing this.  I think I
need to actually find a way to sniff out what IE is doing, but this definitely
isn't working with IE 6 SP1 and Tomcat 5.0.18 on this one SVG page.  (I'm
wondering if it has to do with the form authentication - when I created a test
JSP with no security constraints it worked through IE 6.)

As far as I can tell, though, Tomcat is generating the headers correctly... 
Although I can't figure out why IE would only not work with this page and work
fine on all the others and why back-revving to Tomcat 4 would solve the problem.

And now it appears that Opera 7.23 is working just fine on the page, as well as
Mozilla.  This is probably an Internet Explorer issue, not a Tomcat 5 issue, but
it still is *weird*.  Anyone who has any ideas to help debug what Internet
Explorer is doing would be appreciated - it always indicates that the "Action
was canceled" and says that the site was unavailable.

For reference:


HTTP/1.1 200 OK
Content-Type: image/svg+xml;charset=ISO-8859-1
Date: Wed, 25 Feb 2004 21:28:16 GMT
Server: Apache-Coyote/1.1
Connection: close


HTTP/1.1 200 OK
Pragma: No-cache
Cache-Control: no-cache
Expires: Wed, 31 Dec 1969 19:00:00 EST
Content-Type: image/svg+xml
Date: Wed, 25 Feb 2004 21:21:46 GMT
Server: Apache-Coyote/1.1
Connection: close
Comment 6 william.barker 2004-02-25 22:07:26 UTC
And we have finally found the problem.  In an attempt to try and work around 
some broken client (I can't be bothered to go back and see which one), Tomcat5 
started adding adding the "don't cache" headers even for SSL requests.  I'm in 
a very small minority of disliking this "feature", so it is unlikely to change.

The work-around is to configure the Authenticator yourself:
<Context path="/myapp" docBase="myapp">
  <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
          disableProxyCaching="false" />

Of course, if you're not using Form auth, then substitute the correct class in 
the example above.
Comment 7 Daniel Potter 2004-02-25 22:40:26 UTC
Yep - that solved it.  Thanks!

(Also, I see that Tomcat 5.0.19 was released, so I tested it against that
version and got the same problem on Solaris.)

This is a bug with the way Internet Explorer handles plugins, then.  My guess is
that the file isn't cached so that when the plugin attempts to access it, it
doesn't receive anything causing it to silently fail.

I just tried uploading the Badgers-Badgers SWF and seeing if it would fail in
the same way, and it does.  So this happens with any IE plugin.

Mind you, the way Internet Explorer fails with this is weird.  It just indicates
that the resource is not available, despite all other indications being that it
is.  It also happens when you attempt to directly access the resource through
IE, it asks you to download the file and then tells you that it isn't available.
 It might be worth re-openning this bug and removing the "no-cache" behavior if
"MSIE" appears in the User-agent header.
Comment 8 william.barker 2004-04-28 23:21:34 UTC
*** Bug 28662 has been marked as a duplicate of this bug. ***
Comment 9 william.barker 2004-06-02 16:06:10 UTC
*** Bug 29336 has been marked as a duplicate of this bug. ***
Comment 10 william.barker 2004-07-08 19:42:44 UTC
*** Bug 29975 has been marked as a duplicate of this bug. ***
Comment 11 Sascha C. 2004-07-12 11:58:22 UTC
Microsoft describes the exact behaviour of their bug on this webpage:


Microsoft says that this bug is "by design" and that they will not ifx it. This 
is just SOOO arrogant!!


Tomcat adds the respective caching headers to the HTTP header automatically if 
and only if a resource of a webapp is being accessed for which a user data 
constraint of CONFIDENTIAL has been set.


*** PLUS ***

(Search for 'no-cache' within the connector codebase and put an if(doCaching) 
bracket around it. That's all there is to it.)

I leave it to the tomcat developers to reopen this bug as I regard it as 
somehow impolite to do this myself. However, I strongly recommend you people to 
do so. This bug is reproducible on every InternetExplorer. A lot of people will 
get headaches and spend days on investigation unless you add the proposed 
attribute to the connector configuration or at least place a comment on the 
webpage which informs developers of the effect in question.
Comment 12 william.barker 2004-08-12 15:13:53 UTC
*** Bug 30618 has been marked as a duplicate of this bug. ***
Comment 13 Tim Funk 2004-09-06 12:09:42 UTC
*** Bug 30618 has been marked as a duplicate of this bug. ***
Comment 14 william.barker 2005-09-20 19:13:29 UTC
*** Bug 36735 has been marked as a duplicate of this bug. ***
Comment 15 Chris Lott 2006-02-27 15:24:45 UTC
I would like to add my support for the previous request to make the caching
headers (Pragma and Cache-Control) configurable in Tomcat 5.0.x.  

Brief history: I use Tomcat 5.0.28 for a small webapp.  It sits behind Apache,
which does SSL and forwards requests to Tomcat via mod_jk.  Users access the
webapp stricly with SSL.  The webapp's doc area has a few static power-point
files, and that's where this problem bit me: IE users could not get power-point

To figure out what headers Tomcat sets in responses, I turned on the
RequestDumperValve in the server.xml file.  Then I saw that every single request
-- whether .gif, .html, .css, .ppt, or .jsp -- gets "Cache-Control: no-cache"
and "Pragma: no cache" in the response headers.

While these headers are absolutely appropriate for JSP pages, they are wholly
unnecessary for static content.  I want my users' browsers to cache static
content like CSS sheets, images, etc. and thereby make fewer requests to my
server.  Everybody wins.

This thread helped me understand the problem:

I finally used the solution from here, with one modification:
Jayson Falkner explains servlet filters that set response headers; this means 
web browsers will cache items like pictures and other static content.  Note that
his code does "addHeader" but that does NOT work; you have to do "setHeader" to
overrride the cache-control that Tomcat adds.

I am of the strong opinion that Tomcat needs some configuration setting so users
like me can tell the container what caching policy to apply by default.  Maybe
something along the lines of a mime-types file would allow the caching policy to
be set based on file suffixes or file-name patterns. 

Please consider this request seriously.  I am not a Tomcat dev and don't want to
reopen this bug myself.  Thanks.
Comment 16 John Holman 2007-05-12 09:51:00 UTC
Reopening this bug - even though strictly speaking Tomcat's behaviour is not
incorrect - because it seems to be a significant and common source of problems,
and is not that easy for the user to diagnose. It occurs with or without SSL,
and in a wider set of circumstances than invoking IE plugins. (My own variation
is that download to a file in IE fails if a content-disposition header is set
and the resource is subject to a security constraint).

The workaround given by Bill Barker is to configure each context:

<Context path="/myapp" docBase="myapp">
  <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
          disableProxyCaching="false" />

This works but reduces security more than is necessary, as it causes no cache
control headers to be issued at all.

An alternative workaround

<Context path="/myapp" docBase="myapp">
  <Valve className="org.apache.catalina.authenticator.FormAuthenticator"
          securePagesWithPragma="false" />

is better. It causes a header Cache-Control: private to be issued in place of
the default Cache-Control: none and Pragma: no-cache headers. This tells shared
caches not to cache the response, which I think is all that is necessary, while
still allowing downloads to work in IE.

However, neither workaround is a good solution because it makes configuration
more difficult and because it duplicates knowledge of which authenticator is
required between the web.xml and context.xml files.

Therefore I suggest that AuthenticatorBase be changed to put out the
Cache-Control: private header by default. I think this is simply a matter of
changing the securePagesWithPragma field from true to false:

     * Flag to determine if we disable proxy caching with headers incompatible
     * with IE 
    protected boolean securePagesWithPragma = true;
Other comments in this source file suggest that IE-incompatible headers are
being issued because there is some unspecified problem with Mozilla when
cache-control: private is used. However I can find no such problem at least with
current versions of Firefox. Since the choice therefore seems to be between
working around a known bug in all versions of IE, and working around a possible
bug in some previous versions of Mozilla that does not affect current Firefox
users, I'd argue that the former is the better thing to do. 
Comment 17 Mark Thomas 2007-06-01 18:09:56 UTC
The current behaviour is unlikely to change. I am marking this as an enhancement
rather than WONTFIX in case someone cares enough to come up with a proposed patch.
Comment 18 Dave 2008-07-02 14:41:50 UTC
We just found that adding:

    <web-resource-name>Automatic SLL Forwarding</web-resource-name>

also adds the headers that creates this issue.  Any ideas?  Using tomcat 5.5.25
Comment 19 Mark Thomas 2008-07-02 23:34:43 UTC
<transport-guarantee>CONFIDENTIAL</transport-guarantee> means SSL will be used so yes, you will hit this bug in IE. Workarounds as described above.
Comment 20 Dave 2008-07-03 12:04:44 UTC
We've added the following to context.xml as a work-around:

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

Comment 21 Mark Thomas 2011-05-22 22:49:32 UTC
For reference, the original Mozilla issue described in bug 23887. I have confirmed that this bug no longer exists in the latest version of Firefox. I suspect it was fixed some time ago although I couldn't find it when I tried searching the Mozilla bug database.
Comment 22 Mark Thomas 2011-05-22 22:55:04 UTC
I have removed the Mozilla bug workaround in 7.0.x and changed the default of securePagesWithPragma to false. Both of these changes will be included in 7.0.15 onwards.

I do not intend proposing these changes for back-port.