> -----Original Message----- > From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] > Sent: Tuesday, June 04, 2013 5:51 AM > To: Tomcat Users List > Subject: Re: IE 8 and before refusing to download files (I hate IE) > > 2013/6/4 Jeffrey Janner <jeffrey.jan...@polydyne.com>: > >> -----Original Message----- > >> From: Jeffrey Janner [mailto:jeffrey.jan...@polydyne.com] > >> Sent: Monday, June 03, 2013 3:39 PM > >> To: 'Tomcat Users List'; 'verlag.preis...@t-online.de' > >> Subject: RE: IE 8 and before refusing to download files (I hate IE) > >> > >> > -----Original Message----- > >> > From: verlag.preis...@t-online.de [mailto:verlag.preisser@t- > >> online.de] > >> > Sent: Monday, June 03, 2013 1:28 PM > >> > To: Tomcat Users List > >> > Subject: Re: IE 8 and before refusing to download files (I hate > IE) > >> > > >> > Hi, > >> > > >> > -----Original-Nachricht----- > >> > > Von: Jeffrey Janner <jeffrey.jan...@polydyne.com> > >> > > An: 'Tomcat Users List' <users@tomcat.apache.org> > >> > > >> > > Ran into an interesting problem today. It seems that IE8 and > >> before > >> > > no longer likes how we are sending BLOB files. > >> > > > >> > > Worked last week as far as we can tell. Works fine for IE9+ and > >> > other > >> > > browsers, but IE8 is suddenly giving us an error message, as > >> > > though > >> > it > >> > > is ignoring the response headers. > >> > > > >> > > I'm not going to completely rule out the possibility it is in > our > >> > code > >> > > somewhere, but we haven't found it yet. We did also upgrade out > >> app > >> > > over the weekend, but the problem didn't show up in our test > >> > > environment (as far as we can tell). > >> > > > >> > > Here is the relevant code: > >> > > > >> > [...] > >> > > > >> > > Works great if the MimeType is text/html, but anything else > >> > > generates an error. > >> > > > >> > > The getContent routine reads from the BLOB and copies it to the > >> > > response output stream. > >> > > > >> > > None of this code has changed, and the access log shows a 200 > >> > response > >> > > and the full number of bytes of the file. > >> > > > >> > > Anybody have any ideas? > >> > > > >> > > Server1 specs: Tomcat 6.0.33/Java 1.6.0_33/Windows 2003 SP2 > >> > > Server2 specs: Tomcat 6.0.36/Java 1.6.0_34/Windows 2008 R2/SP1 > >> > > >> > > >> > can you give an example of the actual HTTP response headers that > >> > are sent to the client? > >> > > >> > I just tested that the following response works with IE8 on WinXP > >> > and > >> > IE10 using its IE8-Mode on WIndows 8: > >> > > >> > HTTP/1.1 200 OK > >> > Transfer-Encoding: chunked > >> > Content-Type: application/x-zip-compressed > >> > Server: Microsoft-IIS/7.5 > >> > Content-Disposition: attachment; filename=Portal.zip > >> > Date: Mon, 03 Jun 2013 18:14:14 GMT > >> > > >> > [...] > >> > > >> > This is generated by a Servlet on Tomcat 7.0.40 that sets the > >> Content- > >> > Type and Content-Disposition headers and then writes bytes to the > >> > respone's OutputStream (the response is served by IIS/7.5 using > >> > ISAPI Redirector). For Content-Disposition, I'm using > >> > javax.mail.internet.ContentDisposition which should automatically > >> > add necessary escaping and quoting to the "filename:" part. > >> > > >> > I also tested with IE10's IE7-Mode that is used when activating > >> > Compatibility View and no X-UA-Compatible header is present that > >> tells > >> > IE to use it's highest browser mode (like "X-UA-Compatible: > >> IE=Edge"). > >> > > >> > (As an aside, for my websites I don't support any IE below IE9... > >> > ;-) However, I use the "X-UA-Compatible: IE=Edge" header to > prevent > >> > IE to use the compatibility mode, which can happen if Microsoft > >> > suddenly decides to add your site to its "compatibility view > list", > >> > or sometimes if IE is embedded as ActiveX control etc...) > >> > > >> > > >> > Regards, > >> > Konstantin Preißer > >> > > >> > >> The error presented is "Internet Explorer cannot download from > >> <servlet> from <host-url>. Internet Explorer was unable to open > this > >> Internet site. The request site is either unavailable for cannot be > >> found. Please try again later." > >> > >> But figured it just now. > >> I had removed the line > >> <Valve > className="org.apache.catalina.authenticator.SSLAuthenticator" > >> securePagesWithPragma="false" /> from my context files as it > >> wasn't supposed to be needed, since we don't do SSL Authentication > >> for logins. > >> However, apparently it is setting something in the response header > >> that matters as a side effect of being there. > >> Now I just need to find out what so I can duplicate it with a > filter. > >> > >> Jeff > >> > > > > For those who might be interested, here are the two header sets > returned: > > > > Without SSLAuthenticator: > > HTTP/1.1 200 OK > > Server: Apache-Coyote/1.1 > > Pragma: No-cache > > Cache-Control: no-cache > > Expires: Wed, 31 Dec 1969 18:00:00 CST > > Content-Disposition: attachment; > > > filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV > > %26QUOT%3B_20130603.xls; > > Content-Type: application/vnd.ms-excel > > Transfer-Encoding: chunked > > Date: Mon, 03 Jun 2013 22:34:41 GMT > > > > With SSLAuthenticator: > > HTTP/1.1 200 OK > > Server: Apache-Coyote/1.1 > > Cache-Control: private > > Expires: Wed, 31 Dec 1969 18:00:00 CST > > Content-Disposition: attachment; > > > filename=SITE_VIEW_COST_SAVING_PART_NUMBER_%26QUOT%3BQUOTES_IN_PROJ_SV > > %26QUOT%3B_20130603.xls; > > Content-Type: application/vnd.ms-excel > > Transfer-Encoding: chunked > > Date: Mon, 03 Jun 2013 22:29:41 GMT > > > > Note the only real difference is the addition of a Pragma header. > Apparently, this is giving IE8 and earlier fits. > > Also "Cache-Control" header has a different value. > > Those headers are there to prevent caching of protected resources at > the client (which could result in bypassing the security). If the > resource were not protected then you would not get those headers. > > "securePagesWithPragma" property of > o.a.c.authenticator.AuthenticatorBase has different defaults in Tomcat > 6 (true) vs. recent Tomcat 7 (false). > > A reason to upgrade to Tomcat 7? > > There also exists such property as "disableProxyCaching" there, which > turns off adding of any of those headers. > > > Anybody know how to disable the Pragma being added without using the > SSLAuthenticator Valve? Or remove it? > > > > Servlet 3.0 API allows to inspect and change response headers. Though > there is no method to remove one. > > A Valve can remove a header, though one would have to bother with > Tomcat internals to do so. > > Best regards, > Konstantin Kolinko
Thanks Konstantin, Yes, we are looking at the move to Tomcat 7, but our release cycle hasn't allowed the time for an in-depth study of differences. I think I found the best solution for now, switch to the NonLoginAuthenticator Valve, since I'm not really using SSLAuthentication anyway. It's not really documented, i.e. it's not in the websites list of valves in the documentation section, but it is listed in the API documentation. I'm going to give it a try. All this work to get around a bug in Internet Explorer that's been around for over 10 years. Well, at least they finally fixed it in IE9. Jeff --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
