2010-09-20 120 views
1
private static void writeData(byte[] file, HttpServletResponse response) 
    throws IOException 
{ 
    .... 
    // Send the data 
    response.setContentLength(file.length); 
    response.getOutputStream().write(file); 
} 

最近,我發現在IE8中有一些連接關閉,同時請求文件下載。這是代碼中的相關源代碼片段,我想知道是否一次將大字節數組寫入響應輸出流可能會導致此問題。這個問題非常不可重現,我經常看到一次寫入一定數量的字節的模式,而不是一次寫入,以避免MTU問題或類似問題。將大字節數組寫入輸出流可能會產生什麼影響?

這段代碼是否會對我的間歇性IE問題負責?如果是這樣,爲什麼,爲什麼只在IE瀏覽器?

編輯:

我試着用Cache-Control: no-cache,結果在IE中是災難性的。

alt text

請求:

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] 

響應:

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 

回答

1

您是否正在設置響應的緩存信息? (日期,緩存控制等)

我在IE中見過這種行爲很多,並且總是與IE的緩存實現有關,而不是發送HEAD請求來檢查內容的有效性,它發送完整的GET請求,然後使用頭來確定其緩存內容的有效性,如果它決定緩存版本是有效的,那麼只需關閉連接,這樣就會在服務器端出現很多「斷開的管道」樣式錯誤。

要驗證是這種情況,請嘗試發送緩存控制標題,以便IE始終必須下載完整內容。

+0

這造成了問題。我將嘗試添加Expires:-1和Pragma:no-cache來查看是否可以避免這種引入的破壞。 – 2010-09-21 18:16:22

+0

仍然有失敗。 – 2010-09-21 19:58:53

+0

請解釋你的失敗。 – 2010-09-27 22:23:00

0

由應用程序作出寫入(和刷新)的圖案可以對方式的效果數據包形成併發送,但這似乎是最好的設置:內核具有關於從一開始就要發送的數據的完整信息,並且可以自由選擇數據的最佳分組。

這似乎不太可能是客戶問題的原因。發送帶有潛力的分塊輸出來刷新很多小數據包會更加可疑。

相關問題