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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
Mailing List:     http://jakarta.apache.org/site/mail2.html#poi
The Apache Jakarta Poi Project:  http://jakarta.apache.org/poi/

Gruesse,

Reply via email to