Довжина змісту використовується для опису довжини передачі тіла повідомлення. У протоколі HTTP існує різниця між довжиною сутності повідомлення та довжиною передачі сутності повідомлення, наприклад, при стисненні gzip довжина сутності повідомлення дорівнює довжині до стиснення, а довжина передачі сутності повідомлення — довжиною після стиснення gzip.
У конкретних HTTP-взаємодіях спосіб, як клієнт отримує довжину повідомлення, здебільшого базується на таких правилах:
Якщо відповідь — 1xx, 204, 304 або головний запит, вміст сутності повідомлення ігнорується безпосередньо.
Якщо існує кодування передачі, то метод у кодуванні перенесення віддається перевагі для пошуку відповідної довжини. Наприклад, модель Chunked.
"Якщо в голові є Довжина Змісту, то ця Довжина Змісту представляє і довжину тіла, і довжину передачі. Якщо довжина сутності та довжина передачі не рівні (наприклад, встановлено кодування через передачу), то довжину змісту не можна встановити.Якщо встановлено кодування передачі, то довжину змісту ігноруватимуть”。 Перевага такого перекладу речення полягає в тому, що існує лише одна точка: при кодуванні передачі не може бути довжини змісту.
Передача дальності. Я не звертав уваги, не читав детально :)
Закриття з'єднання через сервер визначає тривалість повідомлення, що передається. (Запитувач не може вказати кінець тіла запиту шляхом закриття з'єднання, оскільки це залишить сервер без можливості продовжити відповідь.) Ця ситуація переважно відповідає коротким з'єднанням, тобто режиму без збереження живого.
HTTP 1.1 має підтримувати режим chunk. Бо коли довжина повідомлення невизначена, цю ситуацію можна вирішити через механізм блокування.
У заголовку, що містить вміст повідомлення, якщо є поле довжини вмісту, відповідне значення поля має точно відповідати довжині теми повідомлення.
"Довжина сутності повідомлення — це довжина тіла повідомлення до застосування будь-яких кодування передачі"
ТобтоЯкщо є шматок, довжини змісту не може бути 。
Механізм постійного з'єднання HTTP/1.0 був впроваджений пізніше і реалізований через заголовок Connection: keep-alive, який може використовуватися як сервером, так і клієнтом, щоб повідомити одне одному, що їм не потрібно відключати TCP-з'єднання після відправлення даних для подальшого використання.HTTP/1.1 вимагає, щоб усі з'єднання були постійними，Якщо тільки ви не додасте чітко Connection: близько до заголовка。 Отже, насправді поле заголовка Connection у HTTP/1.1 більше не має значення keep-alive, але через історичні причини багато веб-серверів і браузерів досі зберігають звичку надсилати Connection: keep-alive на HTTP/1.1 long connections.
Насправді останні кілька можна майже ігнорувати, і короткий підсумок такий:
1. Довжина змісту: якщо вона існує і є дійсною, вона має бути точно такою ж, як довжина передачі вмісту повідомлення. (Перевірили, щоб скоротити, якщо занадто коротко, і занадто довге, щоб спричинити тайм-аут.) ）
2. Якщо існує кодування передачі (фокус розділений на частини), у заголовку не може бути довжини змісту, і це ігнорується.
3. Якщо використовується коротке з'єднання, довжину передачі повідомлення можна визначити безпосередньо шляхом закриття з'єднання через сервер. (Це легко зрозуміти)
У поєднанні з іншими функціями протоколу HTTP, наприклад, Http1.1 не підтримував keep alive. Тоді можна зробити такі висновки:
1. У версіях Http 1.0 та раніше поле довжини вмісту є опціональним.
2. У версіях http1.1 та пізніших. Якщо ви залишаєте живим, то довжина контенту та чанк мають бути одним із двох. Якщо не зберігати живим, це те саме, що й http1.0. Довжини змісту.
|
Опубліковано 24.09.2019 15:53:29
|
|
|
