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 browsers. 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.
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.
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.
Try 'openssl s_client'. It's my first stop when debugging SSL problems.
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".
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: TOMCAT 4.1.29 HEADERS: 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 TOMCAT 5.0.18 HEADERS: 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
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" /> </Context> Of course, if you're not using Form auth, then substitute the correct class in the example above.
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.
*** Bug 28662 has been marked as a duplicate of this bug. ***
*** Bug 29336 has been marked as a duplicate of this bug. ***
*** Bug 29975 has been marked as a duplicate of this bug. ***
Microsoft describes the exact behaviour of their bug on this webpage: http://support.microsoft.com/?id=316431 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. I PROPOSE TO HAVE A SPECIAL ATTRIBUTE WITHIN THE CONNECTOR CONFIGURATION BY WHICH TOMCAT CAN BE FORCED NOT TO SET CACHING HEADERS ITSELF. *** PLUS *** I DON'T LIKE THAT THIS BUG HAS BEEN MARKED AS INVALID! SEVERAL PEOPLE HAVE REPORTED THIS BEHAVIOUR AND a FIX IS POSSIBLE AND STRAIGHTFORWARD TO APPLY. (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.
*** Bug 30618 has been marked as a duplicate of this bug. ***
*** Bug 36735 has been marked as a duplicate of this bug. ***
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 files. 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: http://forum.java.sun.com/thread.jspa?threadID=233446&start=0&tstart=0 I finally used the solution from here, with one modification: http://www.jspinsider.com/content/dev/afessh/another-filter-every-site-should-have.html 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.
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" /> </Context> 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" /> </Context> 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.
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.
We just found that adding: <security-constraint> <web-resource-collection> <web-resource-name>Automatic SLL Forwarding</web-resource-name> <url-pattern>/*</url-pattern> </web-resource-collection> <user-data-constraint> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> </security-constraint> also adds the headers that creates this issue. Any ideas? Using tomcat 5.5.25
<transport-guarantee>CONFIDENTIAL</transport-guarantee> means SSL will be used so yes, you will hit this bug in IE. Workarounds as described above.
We've added the following to context.xml as a work-around: <Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator" disableProxyCaching="true" securePagesWithPragma="false" />
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.
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.