We have had several issues with IE and downloads as well.
I'll try to summarize:
1. Cacheing:
If the cacheing is completely disabled ( setHeader("Expires", 0) and alike -
not 100% sure what header exactly triggered this ), IE will refuse to write
the file to disk - at least when using SSL secured pages. If it is not in
the cache, you cannot display it, and you get "File not found" errors.
This is actually intentional, and not considered a bug by MS.
To set zero-cacheing that works in IE and Mozilla alike (both, http:// and
https://) we use following code:
/* Disabling the caching completely causes an error in IE,
* because IE internally uses the cache-file to provide the data to other
applications.
* No cache file - no data.
* Solution is to allow cacheing (pragma empty), but set
* the expires header to the same value as the date header.
*/
Date now = new Date();
HttpServletResponse response = runData.getResponse();
DateFormat headerDateFormat = new SimpleDateFormat("E, dd MMM yyyy HH:mm:ss
z",new Locale("en"));
headerDateFormat.setTimeZone(TimeZone.getTimeZone("GMT"));
response.setHeader("Date", headerDateFormat.format(now));
response.setHeader("Expires", headerDateFormat.format(now));
response.setHeader("Pragma", "");
response.setHeader("Cache-Control", "must-revalidate");
2. The filename
IE and Mozilla handle the content-disposition: attachment differently.
This is critical when using non-ascii characters in filenames.
AFAIR there was an issue with a "+" character needed by mozilla, but
disallowed by IE.
Mozilla is RFQ compliant, IE is not.
Cannot find the code right now, though...
3. The mime-type.
We use
response.setContentType("application/vnd.ms-excel");
I'm not sure about the filname ending. It was always ".xls" for us in the
content-disposition, but never in the URL...
Hth,
Tobias
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> Sent: Thursday, December 15, 2005 10:33 AM
> To: [email protected]
> Subject: RE: HSSF Failure in IE
>
>
> > This one sends back a 'redirect' to the browser, telling
> > it to fetch outputxls.xls or even
> > outputxls.xls?filename=myworksheet&extension=.xls as the
> > final result.
>
> An alternative I've used is to fetch a filename like:
> > output.xls.jsp?parameters....
>
> According to some MS Knowledge Base article I can't remember,
> even a URL
> like this will trick IE into treating it as a XLS.
>
> Iain
>
>
> -----Original Message-----
> From: Christian Gosch [mailto:[EMAIL PROTECTED]
> Sent: 15 December 2005 08:35
> To: POI Users List
> Subject: Re: HSSF Failure in IE
>
>
> There may be another issue, too, although I am curious about what
> happens when using "Content-Disposition" in correct capitalization.
>
> IE uses different information sources to determine whats
> coming over the
> net, as I said before. I forgot to mention the "extension of the URL".
> Its a bit funny, but it _may_ help to append ".xls" to the
> request which
> finally gets the data.
>
> For example: We have a JSP displaying a link to a struts action which
> does some preprocessing and forwards "externally"
> ("redirect='true'" in
> struts-config.xml) to a servlet effectively producing the result. The
> link on the page is something like preparexls.do which calls something
> like PrepareXlsAction. This one sends back a 'redirect' to
> the browser,
> telling it to fetch outputxls.xls or even
> outputxls.xls?filename=myworksheet&extension=.xls
> as the final result.
>
> If everything else fails, you may check that out additionally.
>
> Regards,
> Christian
>
>
> On Wednesday, December 14, 2005 10:44 AM [GMT+1=CET],
> Nick Burch <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 13 Dec 2005, Dick Hildreth wrote:
> >> content-disposition: attachment; filename=actionitems.xls
> >
> >> Content-disposition: attachment; filename=actionitems.xls
> >
> > The header is called "Content-Disposition", isn't it? (Note the
> > capitalisation - that's the form that RFC2183 has it in anyway)
> >
> > Perhaps IE is being funny about the case?
> >
> > Nick
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > Mailing List: http://jakarta.apache.org/site/mail2.html#poi
> > The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
>
> Gruesse,
> --
> Dipl.-Inform. Christian Gosch
> Systems Development
> inovex GmbH
> Karlsruher Strasse 71
> D-75179 Pforzheim
> Tel.: +49 (0)72 31 - 31 91 - 85
> Fax: +49 (0)72 31 - 31 91 - 91
> mailto:[EMAIL PROTECTED]
> http://www.inovex.de
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> Mailing List: http://jakarta.apache.org/site/mail2.html#poi
> The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
>
>
>
> --------------------------------------------------------------
> ----------
> For more information about Barclays Capital, please
> visit our web site at http://www.barcap.com.
>
>
> Internet communications are not secure and therefore the Barclays
> Group does not accept legal responsibility for the contents of this
> message. Although the Barclays Group operates anti-virus programmes,
> it does not accept responsibility for any damage whatsoever that is
> caused by viruses being passed. Any views or opinions presented are
> solely those of the author and do not necessarily represent
> those of the
> Barclays Group. Replies to this email may be monitored by
> the Barclays
> Group for operational or business reasons.
>
> --------------------------------------------------------------
> ----------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> Mailing List: http://jakarta.apache.org/site/mail2.html#poi
> The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
