Каковы последствия отсутствия заголовка длины содержимого в ответе сервера?

Question

RFC говорит, что заголовок content-length не является обязательным («..Приложения СЛЕДУЕТ использовать это поле ...»).

Из того, что я могу собрать, если он не включен, клиент не будет знать, сколько данных ожидать, поэтому не сможет показывать определенный индикатор выполнения при загрузке тела (то есть верхний бар вместо нижней) ,

Есть ли какие-либо другие побочные эффекты или ошибки, которые возникают из опуская этот заголовок?

Answer 1

Я думаю, что ваш неявный вопрос: «Как клиент обнаруживает конец HTTP-сообщения?». См RFC 7230 - HTTP/1.1 Message Syntax and Routing - Message Body Length:

длина тела сообщения определяется с помощью одного из следующих (в порядке приоритета):

1. Любой ответ на запрос HEAD, и любой ответ с 1xx (Информационный), 204 (без содержимого) или 304 (не измененный) статус код всегда заканчивается первой пустой строкой после полей заголовка , независимо от полей заголовка, присутствующих в сообщении , и, следовательно, не может содержать сообщение тело.

2. Любой 2xx (успешный) ответ на запрос CONNECT означает, что соединение будет туннель непосредственно после пустой линии, которая приходит к выводу поля заголовка. Клиент ДОЛЖЕН игнорировать любые поля заголовка Content-Length или Transfer-Encoding, полученные в таким сообщением.

3. Если поле заголовка Transfer-Encoding присутствует и фрагментированное переноса кодирования (раздел 4.1) является окончательным кодирование, длина тела сообщения определяется путем считывания и декодирования фрагментированное данных до тех пор, кодирование передачи не указывает на то, данные завершены.

   Если поле заголовка Transfer-Encoding присутствует в ответ и фрагментированного кодирование передачи не является окончательным кодирование, то сообщение длина тела определяется путем считывания соединения до тех пор, пока не закрыт сервером. Если поле заголовка Transfer-Encoding присутствует в запросе, а кодированное кодирование передачи не является окончательным кодированием, длина тела сообщения не может быть определена ; сервер ДОЛЖЕН ответить с кодом состояния 400 (Bad Request) , а затем закрыть соединение.

   Если сообщение получено как с передаточным кодированием, так и с полем заголовка Content-Length , то Transfer-Encoding переопределяет Content-Length. Такое сообщение может указывать на попытку выполнить контрабанду запроса (раздел 9.5) или расщепление ответа (раздел 9.4) и должно быть обработано как ошибка. Отправитель ДОЛЖЕН удалять полученное поле Content-Length перед пересылкой такого сообщения вниз по течению.

4. Если сообщение получено без Transfer-Encoding и либо нескольких полей заголовка Content-Length, имеющие различных полевых значений или одно поле Content-Length заголовка, имеющего недопустимого значения, то сообщение кадрирование является недействительным и получатель ДОЛЖЕН рассматривать его как неустранимую ошибку. Если это сообщение с запросом , сервер ДОЛЖЕН ответить с кодом состояния 400 (Bad Request) , а затем закрыть соединение. Если это ответ сообщение, полученное прокси-сервером, прокси ДОЛЖНО закрыть соединение с сервером, отменить полученный ответ и отправить ответ клиенту 502 (Bad Gateway). Если это ответное сообщение , полученное пользовательским агентом, пользовательский агент ДОЛЖЕН закрыть соединение с сервером и отказаться от полученного ответа.

5. Если допустимое поле заголовка Content-Length присутствует без Transfer-Encoding, его десятичное значение определяет ожидаемое сообщение длина тела в октетах. Если отправитель закрывает соединение или истечет время ожидания до того, как указанное количество октетов будет получено , получатель ДОЛЖЕН считать сообщение незавершенным и закрыть соединение.

6. Если это сообщение-запрос, и ни одно из указанных выше не верно, то длина тела сообщения равна нулю (тело сообщения отсутствует).

7. В противном случае, это ответное сообщение без объявленного сообщения длины тела, так что длина тела сообщения определяется числа октетов, полученных до сервера закрывающего соединения.

Когда сервер опускает заголовок длины содержимого, оно должно использовать один из других механизмов, чтобы указать конец сообщения.

Итак, чтобы ответить на ваш вопрос: сценарии 3 (chunking) и 7 (чтение до тех пор, пока сервер не завершит соединение) - это те, где клиент не знает длину заранее.