You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@poi.apache.org by Dick Hildreth <Di...@earthlink.net> on 2005/12/12 02:56:54 UTC
HSSF Failure in IE
I have built an application for creating and displaying an Excel
spreadsheet. It works beautifully when accessed using Mozilla or
Firefox (haven't tested with Netscape) but fails when using MSIE.
It appears that IE refuses to download the file (it also doesn't
recognize the content type) since, when Excel or OOo Calc open, they
complain that the file (in the Temporary Internet Files directory
structure) isn't found. It isn't found for good reason - it isn't there!
From browsing other projects, such as iText on SourceForge, it appears
that IE demands to know how big the stream is (setContentLength).
Unfortunately, I can't figure out how to measure the length to set it
properly. JavaDocs explicitly says that WorkBook.getBytes() "get(s) the
bytes of just the HSSF portions of the XLS file". Apparently, there are
bytes being sent other than these bytes, since stting the ContentLength
to the lenth of getBytes() causes the geckop browsers to fail also.
I would appreciate some insight as to how I might overcome this problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-user-unsubscribe@jakarta.apache.org
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
Re: HSSF Failure in IE
Posted by Dick Hildreth <Di...@earthlink.net>.
Vielen dank, Christian!
I already had the Header Properties set up as you suggest. I set them
in a slightly different order, though I don't expect that would be an issue.
One difference was that I had setDateHeader("Expires", 0) where you have
setHeader("Expires", 0).
I don't understand, however, how to use a byte[] for intermediate
buffering as you suggest. As I noted initially, I tried the
HSSFWorkbook.getBytes() method, but that broke everything. I can't find
another way to implement the byte[] construct.
Any further help would be most welcomed.
Tschuess!
Dick
Christian Gosch wrote:
>(1) Use a byte[] for intermediate buffering, that should tell the truth. If
>things get too big, you may underly a temp file.
>(2) There are RFCs about how to set up the HTTP response header according to
>HTTP 1.0 or 1.1 (therefore you should know what your HTTP server component
>talks to its clients), but for IE that is not really appropriate, because:
>(3) MSIE has really strange methods of claiming knowledge about what is to
>come over the net; nevertheless it is all documented on MS's website. Among
>the strange things is that in older versions (than 6) IE used to send up to
>3 requests to fetch 1 file / resource. (I by myself have seen up to 3
>dialogue boxes asking the user what to do.)
>
>
>We currently succeed on IE6 with some HTTP response header settings like the
>following:
>
> private void setHeaderProperties(HttpServletResponse response, String
>filename) {
> response.setHeader("Cache-Control", "public");
> response.setHeader("Pragma", "public");
> response.setHeader("Expires", "0");
> response.setHeader(
> "Content-Disposition",
> "attachment; filename=\""
> + filename
> + ".xls\";");
> response.setContentType("application/vnd.ms-excel");
> }
>
>
>Notice the content type since it is no 'real' type based on any RFC. This is
>just to confuse the IE file type recognition so that we get a Open/Save box
>for the end user.
>
>After that we calculate the real content byte count by using an intermediate
>byte[], set this value as content length and finally put the byte[] into the
>OutputStream (and flush it).
>
>
>The other thing is that this is NOT TESTED for any other browser than IE
>(because we do not need to care about the better ones ;-) )
>
>
>Regards,
>Christian
>
>
>On Monday, December 12, 2005 2:56 AM [GMT+1=CET],
>Dick Hildreth <Di...@earthlink.net> wrote:
>
>
>
>>I have built an application for creating and displaying an Excel
>>spreadsheet. It works beautifully when accessed using Mozilla or
>>Firefox (haven't tested with Netscape) but fails when using MSIE.
>>
>>It appears that IE refuses to download the file (it also doesn't
>>recognize the content type) since, when Excel or OOo Calc open, they
>>complain that the file (in the Temporary Internet Files directory
>>structure) isn't found. It isn't found for good reason - it isn't
>>there!
>>
>> From browsing other projects, such as iText on SourceForge, it
>>appears that IE demands to know how big the stream is
>>(setContentLength). Unfortunately, I can't figure out how to measure
>>the length to set it properly. JavaDocs explicitly says that
>>WorkBook.getBytes() "get(s) the bytes of just the HSSF portions of
>>the XLS file". Apparently, there are bytes being sent other than
>>these bytes, since stting the ContentLength to the lenth of
>>getBytes() causes the geckop browsers to fail also.
>>
>>I would appreciate some insight as to how I might overcome this
>>problem.
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: poi-user-unsubscribe@jakarta.apache.org
>>Mailing List: http://jakarta.apache.org/site/mail2.html#poi
>>The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/
>>
>>
>
>Gruesse,
>
>
Re: HSSF Failure in IE
Posted by Christian Gosch <c....@inovex.de>.
(1) Use a byte[] for intermediate buffering, that should tell the truth. If
things get too big, you may underly a temp file.
(2) There are RFCs about how to set up the HTTP response header according to
HTTP 1.0 or 1.1 (therefore you should know what your HTTP server component
talks to its clients), but for IE that is not really appropriate, because:
(3) MSIE has really strange methods of claiming knowledge about what is to
come over the net; nevertheless it is all documented on MS's website. Among
the strange things is that in older versions (than 6) IE used to send up to
3 requests to fetch 1 file / resource. (I by myself have seen up to 3
dialogue boxes asking the user what to do.)
We currently succeed on IE6 with some HTTP response header settings like the
following:
private void setHeaderProperties(HttpServletResponse response, String
filename) {
response.setHeader("Cache-Control", "public");
response.setHeader("Pragma", "public");
response.setHeader("Expires", "0");
response.setHeader(
"Content-Disposition",
"attachment; filename=\""
+ filename
+ ".xls\";");
response.setContentType("application/vnd.ms-excel");
}
Notice the content type since it is no 'real' type based on any RFC. This is
just to confuse the IE file type recognition so that we get a Open/Save box
for the end user.
After that we calculate the real content byte count by using an intermediate
byte[], set this value as content length and finally put the byte[] into the
OutputStream (and flush it).
The other thing is that this is NOT TESTED for any other browser than IE
(because we do not need to care about the better ones ;-) )
Regards,
Christian
On Monday, December 12, 2005 2:56 AM [GMT+1=CET],
Dick Hildreth <Di...@earthlink.net> wrote:
> I have built an application for creating and displaying an Excel
> spreadsheet. It works beautifully when accessed using Mozilla or
> Firefox (haven't tested with Netscape) but fails when using MSIE.
>
> It appears that IE refuses to download the file (it also doesn't
> recognize the content type) since, when Excel or OOo Calc open, they
> complain that the file (in the Temporary Internet Files directory
> structure) isn't found. It isn't found for good reason - it isn't
> there!
>
> From browsing other projects, such as iText on SourceForge, it
> appears that IE demands to know how big the stream is
> (setContentLength). Unfortunately, I can't figure out how to measure
> the length to set it properly. JavaDocs explicitly says that
> WorkBook.getBytes() "get(s) the bytes of just the HSSF portions of
> the XLS file". Apparently, there are bytes being sent other than
> these bytes, since stting the ContentLength to the lenth of
> getBytes() causes the geckop browsers to fail also.
>
> I would appreciate some insight as to how I might overcome this
> problem.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: poi-user-unsubscribe@jakarta.apache.org
> 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:c.gosch@inovex.de
http://www.inovex.de
---------------------------------------------------------------------
To unsubscribe, e-mail: poi-user-unsubscribe@jakarta.apache.org
Mailing List: http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta Poi Project: http://jakarta.apache.org/poi/