poi-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dick Hildreth <DickHildr...@earthlink.net>
Subject Re: HSSF Failure in IE
Date Mon, 12 Dec 2005 21:55:12 GMT
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 <DickHildreth@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,
>  
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message