Можно ли просто установить заголовок Transfer-Encoding?
В какой-то момент вызовет Response.Flush(), потому что это произойдет неявно?
ИЗМЕНИТЬ
Нет, я не могу назвать Response.Headers.Add("Transfer-Encoding","anything"); Что бросает.
любые другие предложения?
TL; DR: Указание длины содержимого - лучший способ получить быстрый первый байт; вы разрешите чередование на уровне TCP, а не на уровне HTTP. Если вы не знаете длину контента, настройка context.Response.BufferOutput на false будет отправлять выходные данные, когда он записывает выходной поток с использованием закодированного кодирования передачи.
Почему вы хотите установить Transfer-Encoding: chunked? Перемещенные переводы - это, по сути, обход, позволяющий отправлять документы, длина которых не известна заранее. Однако ASP.NET по умолчанию буферизует весь вывод и, следовательно, знает общую длину содержимого.
Конечно, HTTP накладывается поверх TCP, а за сценой TCP "все равно" разбивает даже монолитный HTTP-ответ на пакеты - это означает, что если вы укажете длину содержимого вверх и отключите буферизацию вывода, ll получить наилучшую задержку, не требуя HTTP-уровня chunking. Таким образом, вам не нужен HTTP-уровень, чтобы обеспечить быстрый первый байт, когда вы знаете длину содержимого.
Хотя я не эксперт по HTTP, я реализовал простой потоковый медиа-сервер с поиском поддержки, динамическим сжатием, кэшированием и т.д., и у меня есть разумное понимание актуальности быстрого первого байта - и chunking как правило, более низкий вариант, если вы знаете длину контента - это почти наверняка, почему ASP.NET не позволит вам установить его вручную - это просто не нужно.
Однако, если вы не знаете длину HTTP-содержимого до того, как передача и буферизация слишком дороги, вы отключите буферизацию вывода, и, по-видимому, сервер будет использовать кодировку с канальной передачей по необходимости.
Когда сервер использует кодированное кодирование передачи? Я просто тестировал, и действительно, если context.Response.BufferOutput установлен на false, а когда длина содержимого не задана, ответ будет разбит; такой ответ на 1-2% больше в моей совершенно ненаучной быстрой проверке документа XML-кодирования размером 1,7 МБ: gzip xml. Поскольку gzip полагается на контекст, чтобы уменьшить избыточность, я ожидал, что коэффициент сжатия будет страдать больше, но кажется, что chunking не обязательно значительно снижает коэффициенты сжатия.
Если вы посмотрите на код фрейма в рефлекторе, кажется, что кодировка передачи действительно устанавливается автоматически по мере необходимости - то есть, если буферизация выключена И длина содержимого не известна И ответ на запрос HTTP/1.1, передача по каналу кодирование. Однако, если сервером является IIS7, и это рабочий запрос ( "интегрированный режим?" ), Код переходит к собственному методу - возможно, с тем же поведением, но я не могу проверить это.
Похоже, вам нужно настроить IIS для этого. IIS 6 имеет свойство AspEnableChunkedEncoding в метабазе, и вы можете увидеть сопоставления IIS 7 для этого в MSDN по адресу http://msdn.microsoft.com/en-us/library/aa965021(VS.90).aspx. Это позволит вам установить TRANSFER-ENCODING: помечено в вашем заголовке. Надеюсь, это поможет.
Если вы установите Buffer на false и оставьте пустую длину содержимого, вам нужно убедиться, что вы отключили функцию "Динамическое сжатие содержимого" для IIS7, чтобы заставить работать с блочным ответом. Кроме того, клиентский браузер должен иметь по крайней мере HTTP 1.1. Режим Chunked не будет работать для HTTP 1.0
Response.Buffer = False
Это установит заголовок HTTP "Tranfer-Encoding: Chuncked" и отправит ответ каждый обзвоненный response.write