Возможные эффекты записи больших байтовых массивов в выходной поток?

Question

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 были катастрофическими.

Запрос:

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

Answer 1

Вы устанавливаете информацию о кешировании ответа? (даты, контроль кэша и т. д.)

Я часто видел такое поведение в IE и всегда связан с реализацией кэширования в IE. Вместо того, чтобы отправлять запрос HEAD для проверки действительности содержимого, он отправляет полный запрос GET, а затем использует заголовки для определения срок действия его кэшированного содержимого, если он решает, что кэшированная версия является действительной, то просто закрывает соединение, поэтому на стороне сервера появляется много ошибок в стиле «сломанный канал».

Чтобы убедиться в этом, попробуйте отправить заголовки управления кэшем, чтобы IE всегда загружал полный контент.

Answer 2

Шаблон записи (и сбросов), выполняемый приложением, может влиять на способ формирования и отправки пакетов, но это выглядит как наилучшая возможная установка: ядро ​​имеет полную информацию о данных, которые должны быть отправлены изначало, и имеет свободу выбора оптимальной пакетизации данных.

Маловероятно, что это станет причиной проблем с клиентом.Отправка фрагментированного вывода с возможностью сброса большого количества крошечных пакетов была бы намного более подозрительной.