Резюме
Как веб-разработчик, я использую протокол Http каждый день, но всегда мало о нем знаю. Эта статья ссылается на спецификацию Http RFC7230 и разбирает часть HTTP-сообщения.
состав сообщения http
start-line: стартовая строка, описывающая основную информацию о запросе или ответе.
*(поле заголовка CRLF): заголовок
CRLF
[message-body]: тело сообщения, фактически передаваемые данные
header
стартовая линия
Формат стартовой линии стартовая строка = строка запроса (строка начала запроса) / (строка начала ответа) строка состояния
заголовок
Эти форматы являются правилами, используемыми для разбора
приказТеоретически порядок ключей в поле заголовка не имеет значения, но лучше всего размещать контрольное поле впереди, например, Хост и Дата ответа при запросе, чтобы можно было узнать, нужно ли его обрабатывается как можно быстрее.
повторениеКромеSet-Cookie
Этот ключ, ничего больше, если отправитель отправит дубликат ключа, получатель его объединит, а значения будут разделены запятыми.
Полевые ограниченияСам протокол не имеет ограничений на каждое поле заголовка, но в инженерной практике наработаны некоторые наработки, и нет общих ограничений, которые связаны со специфической семантикой полей. Не существует определенного стандартного значения для общего предела размера заголовка, некоторые из них составляют 4 КБ, некоторые — 8 КБ. Сторона сервера проверяет, что заголовок заголовка превышает предельное значение, и он не будет проигнорирован из соображений безопасности. Вместо этого будет выдана ошибка 4XX.
ТолькоHost
Поле обязательно в заголовке запроса, остальные значения не имеют.
поле | заголовок запроса | заголовок ответа | объяснять |
---|---|---|---|
Host | 1 | 0 | сообщить серверу, какой хост должен его обрабатывать |
User-Agent | 1 | 0 | Идентифицирует тип браузера, хотя он использовался плохо и не очень надежен, но иногда его можно использовать для настройки типа |
Accept | 1 | 0 | Допустимый тип mime типа body, например text/html |
Accept-Charset | 1 | 0 | приемлемый набор символов |
Accept-Encoding | 1 | 0 | Допустимые форматы кодирования |
Accept-Language | 1 | 0 | Может принимать несколько языков |
Content-Type | 1 | 1 | Отправленный тип тела типа mime |
Content-Encoding | 1 | 1 | отправленный код |
Content-Language | 1 | 1 | язык отправлен |
Вот полная категорияdeveloper.Mozilla.org/en-US/docs/…
body
Заголовок обязателен, но не обязательно использовать тело.
body — это содержимое передачи. Поскольку Http является протоколом прикладного уровня, помимо передачи данных также необходимо определить формат передаваемых данных. Эти определения формата указаны в заголовке.Content-Length
Длина тела запроса или ответа должна сопровождаться этим полем, чтобы другая сторона могла легко различить границу сообщения, то есть когда заканчиваются данные тела. Если Тело слишком большое, то его необходимо передавать при расчете. До конца расчета невозможно узнать размер всего Тела. В это время можно использовать передачу фрагментов.Transfer-Encoding
Укажите, что эти два ключа заголовка являются взаимоисключающими, и может быть указан только один.Если указаны два ключа заголовка, получатель отдаст приоритет обработкеTransfer-Encoding
поле. Обычно, когда данных тела много, для передачи используются чанки, что более эффективно. Если длины нет, как узнать, что передача данных завершена?Через чанк с длиной 0 соответствующие чанковые данные не имеют содержимого, указывающего на конец содержимого тела.
что сделал джетти
jetty — это веб-контейнер, который должен анализировать Http-запрос и отправлять Http-ответ. Что ты сделал в следующий раз?
Обратите внимание на паблик-аккаунт [Abbot's Temple], как можно скорее получите обновление статьи и начните путь технической практики вместе с настоятелем
Ссылаться на
tools.I ETF.org/PDF/RFC7230… developer.Mozilla.org/en-US/docs/…