Thank you very much for the information. However, I also had to to change Cache-Control value (no-cache => cache) too. Anyway thank you for your answer
On Mon, 18 Oct 2004 15:03:10 +0100, Jon Wingfield <[EMAIL PROTECTED]> wrote: > Tomcat adds (or at least did in the 4.1 branch) certain response > headers, directives to clients and proxy caches to not cache the data, > when it is to serve something within a security-constraint. (log > examples at end of post) > > [It seems that] When IE downloads something with a mime-type it thinks > it can handle (probably via a plug-in) it caches the data and then > passes it over to the plug-in. With SSL and the Pragma header set to > no-cache this seems to fail with the error message described in the > original post. > > Our entire site is SSL also and we've seen this error (and our hack > resolves it) for csv, excel, pdf files. Downloading with the > content-type set to application/octet-stream doesn't trigger the error > in our experience (we also provide this option on the download pages but > users generally want to see the data directly). > > Jon > > Examples from my 4.1.29 logs when the RequestDumperValve is commented in: > > Response for index.jsp (inside security-constraint): > authType=null > contentLength=-1 > contentType=null > cookie=JSESSIONID=EB28F372EF5D5FC5C2908C57766010BA; domain=null; path=/ > header=Pragma=No-cache > header=Cache-Control=no-cache > header=Expires=Thu, 01 Jan 1970 00:00:00 GMT > header=Set-Cookie=JSESSIONID=EB28F372EF5D5FC5C2908C57766010BA; Path=/ > header=Location=http://localhost:8080/login.jsp;jsessionid=EB28F372EF5D5FC5C2908C57766010BA > message=null > remoteUser=null > status=302 > > Response for bgdot.gif (outside security-constraint): > authType=null > contentLength=77 > contentType=image/gif;charset=ISO-8859-1 > header=Server=IMP/4.0.20 > header=ETag=W/"77-1098106680000" > header=Last-Modified=Mon, 18 Oct 2004 13:38:00 GMT > message=null > remoteUser=null > status=200 > > > > David Wall wrote: > > > Our web site is entirely SSL. Most users have IE. Our application is used > > to securely transfer and digitally sign attached files that must be > > downloaded. Yet, we've never seen this problem. Who is putting in the > > "Pragma" header in the response in the first place that you have to change > > it this way? And why does the Pragma setting have the negative effect > > described? > > > > Thanks, > > David > > > > ----- Original Message ----- > > From: "Jon Wingfield" <[EMAIL PROTECTED]> > > To: "Tomcat Users List" <[EMAIL PROTECTED]> > > Sent: Friday, October 15, 2004 9:57 AM > > Subject: Re: Internet Explorer Bug under SSL Connection > > > > > > > >>Yep. This comes up every so often on the list. > >> > >>Whenever IE downloads content we change the Pragma response header to be > >>public instead of no-cache: > >> > >>String userAgent = request.getHeader("user-agent"); > >>if (response.containsHeader("Pragma") > >> && userAgent!=null > >> && userAgent.toUpperCase().indexOf("MSIE")>-1) { > >> response.setHeader("Pragma", "public"); > >>} > >> > >> > >>HTH, > >> > >>Jon > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
