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

Question

RFC говорит, что content-length заголовок необязателен ("..Applications ДОЛЖЕН использовать это поле...").

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

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

Answer 1

Я думаю, что ваш неявный вопрос "Как клиент обнаруживает конец HTTP-сообщения?", См. RFC 7230 - Синтаксис и маршрутизация сообщений HTTP/1.1 - Длина тела сообщения:

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

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

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

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

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

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

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

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

6. Если это сообщение запроса и ни одно из вышеперечисленного не соответствует действительности, тогда длина тела сообщения равна нулю (тело сообщения отсутствует).

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

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

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