tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@gmail.com>
Subject Re: IE 8 and before refusing to download files (I hate IE)
Date Tue, 04 Jun 2013 10:50:51 GMT
2013/6/4 Jeffrey Janner <Jeffrey.Janner@polydyne.com>:
>> -----Original Message-----
>> From: Jeffrey Janner [mailto:Jeffrey.Janner@PolyDyne.com]
>> Sent: Monday, June 03, 2013 3:39 PM
>> To: 'Tomcat Users List'; 'verlag.preisser@t-online.de'
>> Subject: RE: IE 8 and before refusing to download files (I hate IE)
>>
>> > -----Original Message-----
>> > From: verlag.preisser@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.Janner@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message