HTTP-запросы — это сообщения, отправляемые клиентом для инициирования действия на сервере. Их строка начального состояния содержит три элемента:

1. Метод HTTP, глагол (например, GET, PUT или POST) или существительное (например, HEAD или OPTIONS), описывающее действие, которое должно быть выполнено. Например, GET указывает, что ресурс должен быть получен, или POST означает, что данные отправляются на сервер (создание или изменение ресурса или генерация временного документа для отправки обратно).
2. Цель запроса, обычно URL или абсолютный путь протокола, порта и домена обычно характеризуются контекстом запроса. Формат этой цели запроса варьируется в зависимости от разных методов HTTP. Он может быть
   • Абсолютным путем, за которым следует '?' и строка запроса. Это наиболее распространенная форма, известная как форма происхождения, и используется с методами GET, POST, HEAD, и OPTIONS.
     • POST / HTTP/1.1
     • GET /background.png HTTP/1.0
     • HEAD /test.html?query=alibaba HTTP/1.1
     • OPTIONS /anypage.html HTTP/1.0
   • Полный URL, известный как абсолютная форма, в основном используется с GET при подключении к прокси. GET https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages HTTP/1.1
   • Компонент авторитета URL, состоящий из имени домена и необязательно порта (префикс ':'), называется формой авторитета. Он используется только с CONNECT при настройке HTTP-туннеля. CONNECT developer.mozilla.org:80 HTTP/1.1
   • Форма со звездочкой, простая звездочка ('*') используется с OPTIONS, представляя сервер в целом. OPTIONS * HTTP/1.1
3. Версия HTTP, определяющая структуру оставшегося сообщения, являющаяся индикатором ожидаемой версии для использования в ответе.

Заголовки HTTP из запроса следуют той же основной структуре HTTP-заголовка: регистронезависимая строка, за которой следует двоеточие (':') и значение, структура которого зависит от заголовка. Весь заголовок, включая значение, состоит из одной единственной строки, которая может быть довольно длинной.

В запросах может присутствовать множество различных заголовков. Их можно разделить на несколько групп:

• Общие заголовки, такие как Via, относятся к сообщению в целом.
• Заголовки запроса, такие как User-Agent или Accept, дополнительно описывают запрос (например, Accept-Language), обеспечивают контекст (например, Referer) или условно ограничивают его (например, If-None).
• Заголовки представления, такие как Content-Type, которые описывают исходный формат данных сообщения и применяемое кодирование (присутствуют только в случае наличия тела сообщения).

Заключительная часть запроса — его тело. Не все запросы его содержат: запросы, получающие ресурсы, например, GET, HEAD, DELETE, или OPTIONS, обычно не нуждаются в теле. Некоторые запросы отправляют данные на сервер для его обновления: как часто бывает в случае с POST запросами (содержащими данные HTML-формы).

Тела можно условно разделить на две категории:

• Тела с одним ресурсом, состоящие из одного файла, определенного двумя заголовками: Content-Type и Content-Length.
• Тела с несколькими ресурсами, состоящие из многочастного тела, каждое из которых содержит различные данные. Обычно это связано с HTML-формами.

Строка начального состояния HTTP-ответа, называемая строкой состояния, содержит следующую информацию:

1. Версия протокола, обычно HTTP/1.1.
2. Код состояния, указывающий на успешность или неудачу запроса. Общие коды состояния — 200, 404 или 302
3. Текст состояния. Краткое, сугубо информативное, текстовое описание кода состояния, помогающее человеку понять HTTP-сообщение.

Типичная строка состояния выглядит так: HTTP/1.1 404 Not Found.

Заголовки HTTP для ответов следуют той же структуре, что и любой другой заголовок: регистронезависимая строка, за которой следует двоеточие (':') и значение, структура которого зависит от типа заголовка. Весь заголовок, включая значение, отображается в одной строке.

В ответах может присутствовать множество различных заголовков. Их можно разделить на несколько групп:

• Общие заголовки, такие как Via, относятся к всему сообщению.
• Заголовки ответа, такие как Vary и Accept-Ranges, предоставляют дополнительную информацию о сервере, которая не помещается в строку состояния.
• Заголовки представления, такие как Content-Type, которые описывают исходный формат данных сообщения и применяемое кодирование (присутствуют только в случае наличия тела сообщения).

Последняя часть ответа — тело. Не все ответы его содержат: ответы с кодом состояния, который адекватно отвечает на запрос без необходимости соответствующей полезной нагрузки (например, 201 Created или 204 No Content) обычно не нуждаются в нём.

Тела можно условно разделить на три категории:

• Тела с одним ресурсом, состоящие из одного файла известной длины, определенного двумя заголовками: Content-Type и Content-Length.
• Тела с одним ресурсом, состоящие из одного файла неизвестной длины, закодированные частями с Transfer-Encoding значением chunked.
• Тела с несколькими ресурсами, состоящие из многочастного тела, каждое из которых содержит разные части информации. Они встречаются относительно редко.

Сообщения HTTP/1.x имеют несколько недостатков с точки зрения производительности:

• Заголовки, в отличие от тел, не сжаты.
• Заголовки часто очень похожи из одного сообщения в другое, но всё же повторяются в соединениях.
• Невозможно выполнить мультиплексирование. Для нескольких подключений к одному серверу необходимо открывать несколько соединений: тёплые TCP-соединения эффективнее холодных.

HTTP/2 вводит дополнительный этап: он разбивает сообщения HTTP/1.x на фреймы, которые встроены в поток. Данные и фреймы заголовков разделены, что позволяет сжимать заголовки. Несколько потоков можно объединить, процесс, называемый мультиплексированием, что позволяет более эффективно использовать основанные на TCP соединения.

HTTP-фреймы теперь прозрачны для веб-разработчиков. Это дополнительный шаг в HTTP/2, между сообщениями HTTP/1.1 и протоколом транспортного уровня. Для использования HTTP-фреймов не требуются изменения в API, используемых веб-разработчиками; при наличии в браузере и на сервере HTTP/2 включается и используется.

HTTP-сообщения являются ключевыми при использовании HTTP; их структура проста и они очень расширяемы. Механизм фрейминга HTTP/2 добавляет новый промежуточный уровень между синтаксисом HTTP/1.x и основным транспортным протоколом, не изменяя его фундаментально: он строится на проверенных механизмах.