Search code examples
javainternet-explorer-8streamingweblogic

Possible effects of writing large byte arrays to an output stream?

private static void writeData( byte[] file, HttpServletResponse response )
    throws IOException
{
    ....
    // Send the data
    response.setContentLength(file.length);
    response.getOutputStream().write(file);
}

Recently, I've found in IE8 that some connections close while requesting files to download. This is the relevant piece of source in code, and I was wondering if writing large byte arrays all at once to the response output stream could cause this issue. The issue is very much non-reproducible, and I've often seen the pattern of writing a certain number of bytes at a time, versus all at once, to avoid MTU issues, or something like that.

Could this code be responsible for my intermittent IE issues? If so, why, and why only in IE?

Edit:

I tried using Cache-Control: no-cache, and the results were catastrophic in IE.

alt text

Request:

POST /myapplication/someAction.do?step=none&SAct=none HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, */*
Referer: https://myhost.myhost.com/myapplication/someAction.do?queryString=something
Accept-Language: en-US
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; InfoPath.3)
Content-Type: application/x-www-form-urlencoded
Accept-Encoding: gzip, deflate
Host: myhost.myhost.com
Content-Length: 1644
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: JSESSIONID=GnvHMYyGx9QrmpVQfBSgNXnPM8nQJ21dT82KhmSSTXRRT1mgB8tP!299858932; [truncated]

Response:

HTTP/1.1 200 OK
Cache-Control: no-cache
Date: Tue, 21 Sep 2010 18:00:56 GMT
Transfer-Encoding: chunked
Content-Type: application/ZIP
Content-Disposition: inline; filename=ActivityReport.ZIP
X-Powered-By: Servlet/2.5 JSP/2.1
Solution

  • Are you setting response's caching information? (dates, cache-control, etc.)

    I've seen this behavior in IE a lot, and always has to do with IE's implementation of caching, instead of sending a HEAD request to check contents' validity, it sends the full GET request and then uses headers to determine the validity of its cached content, if it decides the cached version is valid, then just closes the connection, so a lot of "broken pipe" style errors show up on server side.

    To verify this is the case, try sending cache control headers so IE always has to download the full content.