Длина содержания используется для описания длины передачи тела сообщения. В протоколе HTTP существует разница между длиной сущности сообщения и длиной передачи этого сущности, например, при gzip-сжатии длина сущности сообщения — это длина до сжатия, а длина передачи сообщения — длина после gzip-сжатия.
В конкретных HTTP-взаимодействиях способ получения длины сообщения клиентом в основном зависит от следующих правил:
Если ответ — 1xx, 204, 304 или головный запрос, содержимое сущности сообщения напрямую игнорируется.
Если существует кодировка трансфера, то метод в кодировке переноса предпочтительнее для поиска соответствующей длины. Например, модель Chunked.
«Если в голове есть Содержание-Длина, то эта Содержимая Длина представляет и длину тела, и длину передачи. Если длина сущности и длина переноса не равны (например, задано кодирование передачи), то длина содержания не может быть установлена.Если задано кодирование передачи, то длина содержимого будет игнорироваться”。 Преимущество такого перевода предложения в том, что есть только один момент: при кодировании переноса не может быть Content-Length.
Передача дальности. Я не обращал внимания, не читал подробно :)
Закрытие соединения через сервер определяет длину передаваемого сообщения. (Запросчик не может указать конец тела запроса при закрытии соединения, так как это оставит сервер без возможности продолжить ответ.) Эта ситуация в основном соответствует коротким соединениям, то есть режиму без сохранения живых.
HTTP 1.1 должен поддерживать режим фрагментов. Потому что когда длина сообщения неопределена, эта ситуация может быть решена через механизм чанка.
В заголовке, содержащем содержимое сообщения, если есть поле с длиной содержимого, соответствующее значение поля должно точно совпадать с длиной темы сообщения.
«Длина сущности сообщения — это длина тела сообщения до применения любых кодировок передачи»
То естьЕсли есть фрагмент, длины содержимого не может быть 。
Механизм постоянного соединения HTTP/1.0 был введён позже и реализован через заголовок Connection: keep-alive, который может использоваться как сервером, так и клиентом для сообща друг другу, что им не нужно отключать TCP-соединение после отправки данных для последующего использования.HTTP/1.1 требует, чтобы все соединения были постоянными，Если только явно не добавить Connection: близко к заголовку。 Таким образом, на самом деле поле заголовка Connection в HTTP/1.1 больше не имеет значения keep-alive, но по историческим причинам многие веб-серверы и браузеры всё ещё сохраняют привычку отправлять длинные соединения Connection: keep-alive в HTTP/1.1.
На самом деле, последние несколько можно почти игнорировать, и краткое резюме такова:
1. Длина содержимого: если она существует и валидна, она должна совпадать с длиной передачи содержимого сообщения. (Тестировалось, чтобы урезать, если слишком коротко, и слишком длинно, чтобы вызвать тайм-аут.) ）
2. Если существует кодирование передачи (фокус фрагментирован), в заголовке не может быть длины содержания, и он будет игнорирован.
3. Если используется короткое соединение, длина передачи сообщения может быть определена напрямую, закрывая соединение через сервер. (Это легко понять)
В сочетании с другими функциями протокола HTTP, например, Http1.1 не поддерживал сохранение живым. Тогда можно сделать следующие выводы:
1. В версиях Http 1.0 и более ранних вариантов поле длины содержания является необязательным.
2. В http1.1 и более поздних версиях. Если вы сохраняете жизнь, то длина контента и чанк должны быть одними из двух. Если он не сохраняется живым, то это то же самое, что и http1.0. Содержание.
|
Опубликовано 24.09.2019 15:53:29
|
|
|
