RFC 2616 HTTP-длина содержимого и совместимость кодировки передачи

Question

RFC 2616 утверждает, что заголовок Content-Length не должен отправляться, если присутствует Transfer-Encoding.

Поле заголовка Content-Length НЕ ДОЛЖНО отправляться, если эти две длины различны (т. Е. Если присутствует поле заголовка Transfer-Encoding).

Однако, если оба заголовка получены, клиент должен игнорировать Content-Length

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

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

Я спрашиваю, потому что стандартный пакет Go net/http возвращает ошибку при таком сценарии.

Answer 1

Стандарт на самом деле не указывает, что должно произойти в этом случае, только если сообщение принято вообще, то Content-length следует игнорировать.Цитировать из RFC 7230 :

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

Обратите внимание на слабое "должно" , что далеко от ДОЛЖНО.Но, по крайней мере, net/http полностью корректен в том смысле, что этот тип ответа неверен, и может быть обработан как ошибка .Но необязательно рассматривать как ошибку .

На практике все браузеры, похоже, принимают такой ответ и обычно игнорируют заголовок Content-length.Но в прошлом я видел такое же поведение с MS Edge, когда оно правильно обрабатывало тело ответа как фрагментированное, но дополнительно использовало Content-length и игнорировало любые байты из тела ответа, не охватываемого Content-length.