HTTP протокол

Hypertext Transfer Protocol, HTTP (протокол передачи гипертекста) — это протокол прикладного уровня передачи данных, изначально — в виде гипертекстовых документов в формате HTML, в настоящее время используется для передачи произвольных данных. Это основа для передачи данных во Всемирной паутине (то есть в Интернете) с 1990 года. HTTP — это протокол общего назначения без сохранения состояния, который можно использовать для других целей, а также с использованием расширения методов запроса, кодов ошибок и заголовков.

По сути, HTTP — это протокол связи на основе TCP/IP, который используется для доставки данных (файлов HTML, файлов изображений, результатов запросов и т. д.) по Всемирной паутине. Порт по умолчанию — TCP 80, но можно использовать и другие порты. Он обеспечивает стандартизированный способ взаимодействия компьютеров друг с другом. Спецификация HTTP определяет, как данные запросов клиентов будут создаваться и отправляться на службу, и как серверы отвечают на эти запросы.

Основные характеристики

Существуют следующие три основные особенности, которые делают HTTP простым, но мощным протоколом:

Изначально HTTP работал без сохранения соединения схема процесса была следующей: HTTP-клиент, т.е. браузер, инициирует HTTP-запрос, и после того, как запрос сделан, клиент отключается от сервера и ждёт ответа. Сервер обрабатывает запрос и повторно устанавливает соединение с клиентом, чтобы отправить ответ. В HTTP/0.9 и 1.0 соединение закрывается после одной пары запрос/ответ, это была очень простая реализация. В HTTP/1.1 был введён механизм keep-alive, при котором соединение можно было повторно использовать для более чем одного запроса. Такие постоянные соединения заметно сокращают задержку запроса, поскольку клиенту не нужно повторно согласовывать соединение TCP 3-Way-Handshake после отправки первого запроса.
HTTP не зависит от типа контента: это означает, что любой тип данных может быть отправлен по HTTP, если и клиент, и сервер знают, как обрабатывать содержимое данных. Для клиента и сервера необходимо, чтобы был указан тип контента, для этого используется соответствующий MIME-тип.
HTTP не имеет состояния: HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Сервер и клиент знают друг друга только во время текущего запроса. После этого они оба забывают друг о друге. Из-за такого характера протокола ни клиент, ни браузер не могут сохранять информацию между различными запросами на веб-страницах. Но компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

HTTP/1.0 использует новое соединение для каждого обмена запрос/ответ, тогда как соединение HTTP/1.1 может использоваться для одного или нескольких обменов запрос/ответ. Версия 1.1 протокола также улучшила оптимизацию полосы пропускания для HTTP/1.0. Например, в HTTP/1.1 введено кодирование передачи по частям, позволяющее передавать контент в постоянных соединениях в потоковом режиме, а не в буфере. Конвейерная обработка HTTP дополнительно сокращает время задержки, позволяя клиентам отправлять несколько запросов, прежде чем ждать каждого ответа. Ещё одним дополнением к протоколу стало побайтовое обслуживание (byte serving), когда сервер передаёт только часть ресурса, явно запрошенную клиентом. Протокол HTTP/2 является бинарным. Среди ключевых особенностей: мультиплексирование запросов, расстановка приоритетов для запросов, сжатие заголовков, загрузка нескольких элементов параллельно посредством одного TCP-соединения, поддержка проактивных push-уведомлений со стороны сервера. HTTP/3 – предлагаемый последователь HTTP/2.

Базовая архитектура

На следующей диаграмме показана очень простая архитектура веб-приложения и показано, где находится HTTP:

Протокол HTTP — это протокол запроса/ответа, основанный на архитектуре клиент/сервер, где веб-браузер, роботы, поисковые системы и т. д. действуют как HTTP-клиенты, а веб-сервер действует как сервер.

Сеанс HTTP — это последовательность сетевых транзакций запрос-ответ.

Клиент

HTTP-клиент через TCP/IP соединение отправляет запрос на сервер, используя один из методов запросов (они будут рассмотрены ниже), URI и версию протокола, за которым следует MIME-подобное сообщение, содержащее модификаторы запроса, информацию о клиенте и возможное содержимое тела. Типичные HTTP клиенты — веб-браузеры. Но также HTTP клиентами являются программы для скачивания файлов, скачивания обновлений ОС, веб-пауки (краулеры).

Сервер

HTTP-сервер, прослушивающий порт, на который пришёл запрос, отвечает строкой состояния, включающую версию протокола сообщения и код успеха или ошибки, за которыми следует MIME-подобное сообщение, содержащее информацию о сервере, метаинформацию объекта и возможное содержимое тела объекта.

Параметры

В этой главе будет перечислено несколько важных параметров протокола HTTP и их синтаксис в том виде, в котором они используются при обмене данными. Например, формат даты, формат URL-адреса и т. д. Это поможет вам в построении ваших сообщений запроса и ответа при написании клиентских или серверных программ HTTP. Вы увидите полное использование этих параметров в следующих главах, объясняющих структуру сообщений для HTTP-запросов и ответов.

Версия HTTP

HTTP использует схему нумерации <major>.<minor> для обозначения версий протокола. Версия сообщения HTTP указывается в поле HTTP-Version в первой строке.

Пример:

HTTP/1.0

Или:

HTTP/1.1

Универсальные идентификаторы ресурсов (URI)

Унифицированные идентификаторы ресурсов (URI) — это просто отформатированная строка без учёта регистра, содержащая имя, местоположение и прочее для идентификации ресурса, например веб-сайта, веб-службы и т. п. Общий синтаксис URI, используемый для HTTP, выглядит следующим образом:

http://хост[":"порт][/абс_путь["?"запрос]]

Части, помещённые в квадратные скобки, являются необязательными.

Здесь, если порт пуст или не задан, предполагается, что порт 80 для HTTP, а пустой абс_путь эквивалентен "/". Символы, отличные от символов в зарезервированном и небезопасном наборах (об этом ниже), заменяются эквивалентами в кодировке %HEX.

Пример. Следующие три URI эквивалентны:

http://abc.com:80/~smith/home.html
http://ABC.com/%7Esmith/home.html
http://ABC.com:/%7esmith/home.html

Форматы даты/времени

Все метки даты и времени HTTP ДОЛЖНЫ быть представлены во времени по Гринвичу (GMT), без исключения. Приложениям HTTP разрешено использовать любое из следующих трёх представлений меток даты/времени:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Наборы символов (charset)

В HTTP указание на набор символов используется чтобы указать наборы символов, которые предпочитает клиент. Можно указать несколько наборов символов через запятую. Если значение не указано, по умолчанию используется US-ASCII.

Пример. Ниже приведены допустимые наборы символов:

US-ASCII

или

ISO-8859-1

или 

ISO-8859-7

или 

UTF-8

То есть это кодировка текста.

Кодирование контента

Значения кодирования содержимого указывают на то, какой алгоритм кодирования использовался для обработки содержимого перед его передачей по сети. Кодирование содержимого в основном используется для того, чтобы документ можно было сжать или иным образом преобразовать с пользой без потери идентичности.

Все значения кодирования содержимого нечувствительны к регистру. HTTP/1.1 использует значения кодирования содержимого в полях заголовка Accept-Encoding и Content-Encoding, которые мы увидим в следующих главах.

Пример. Ниже приведены допустимые схемы кодирования:

Accept-encoding: gzip

или

Accept-encoding: compress

или 

Accept-encoding: deflate

Не следует путать кодировку (которая называется «наборы символов») и кодирование. Кодировка/наборы символов — это то, какие символы использовались для содержимого, а кодирование — это метод обработки перед отправкой.

Типы медиа

HTTP использует Internet Media Types (Интернет-типы мультимедиа) в полях заголовка Content-Type и Accept для обеспечения открытой и расширяемой типизации данных и согласования типов. Все значения типа медиа регистрируются в Internet Assigned Number Authority ((IANA). Ниже приводится общий синтаксис для указания типа медиа:

тип/подтип

В именах атрибутов типа и подтипа регистр не учитывается.

Пример:

Accept: image/gif

Языковые теги

HTTP использует языковые теги в полях Accept-Language и Content-Language. Тег языка состоит из одной или нескольких частей: основного тега языка и серии вложенных тегов, которая может быть пустой.

ТЭГ[-ПОДТЭГ]

Пробелы внутри тега не допускаются, и все теги нечувствительны к регистру.

Примеры тегов:

en
en-US
en-cockney
i-cherokee
x-pig-latin
ru-RU
ru

Пример HTTP заголовка:

Accept-Language: en-US,en;q=0.9,ru-RU;q=0.8,ru;q=0.7

Там где двухбуквенный первичный тег, то это аббревиатура языка ISO-639, а там где двухбуквенный начальный вложенный тег, то это код страны ISO-3166.

Сообщения

HTTP основан на модели архитектуры клиент-сервер и протоколе запросов/ответов без сохранения состояния, который работает путём обмена сообщениями через надёжное соединение TCP/IP.

HTTP-клиент — это программа (веб-браузер или любой другой клиент), которая устанавливает соединение с сервером с целью отправки одного или нескольких сообщений HTTP-запроса. HTTP-сервер — это программа (как правило, веб-сервер, такой как веб-сервер Apache или IIS Internet Information Services и т. д.), которая принимает соединения для обслуживания HTTP-запросов путём отправки сообщений HTTP-ответа.

HTTP использует унифицированный идентификатор ресурса (URI) для идентификации данного ресурса и установления соединения. После установления соединения HTTP-сообщения передаются в формате, аналогичном формату, используемому в Интернет-почте [RFC5322] и в многоцелевых расширениях Интернет-почты (MIME) [RFC2045]. Эти сообщения состоят из запросов от клиента к серверу и ответов от сервера к клиенту.

Каждое HTTP-сообщение состоит из следующих частей, которые передаются в указанном порядке:

Стартовая строка (англ. Starting line) — определяет тип сообщения;
Заголовки (англ. Headers) — характеризуют тело сообщения, параметры передачи и прочие сведения; после каждой строки следует символ CRLF
Пустая строка (то есть строка, в которой ничего не предшествует CRLF), она обозначает конец полей заголовка
Тело сообщения (англ. Message Body) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Тело сообщения может отсутствовать, но стартовая строка и заголовок являются обязательными элементами. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа — только тело сообщения.

Для версии протокола 1.1 сообщение запроса обязательно должно содержать заголовок Host.

Стартовая строка сообщения

Стартовые строки различаются для запроса и ответа.

Мы обсудим строку запроса и строку состояния при обсуждении сообщений HTTP-запроса и HTTP-ответа соответственно. А пока посмотрим на примеры начальной строки в случае запроса и ответа:

Это строка запроса, отправленная клиентом:

GET /hello.htm HTTP/1.1

Это строка состояния, отправленная сервером:

HTTP/1.1 200 OK

Для версии протокола 0.9 в строке запроса отсутствовала версия, то есть она выглядела бы так:

GET /hello.htm

Стартовая строка ответа сервера имеет следующий формат:

HTTP/Версия КодСостояния Пояснение

где:

Версия — пара разделённых точкой цифр, как в запросе;
Код состояния (англ. Status Code) — три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента;
Пояснение (англ. Reason Phrase) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:

HTTP/1.0 200 OK

Поля заголовка

Поля HTTP заголовка предоставляют необходимую информацию о запросе или ответе или об объекте, отправленном в теле сообщения. Существует четыре типа заголовков HTTP-сообщений:

General (Общие заголовки): эти поля заголовка имеют общее применение как для сообщений запроса, так и для сообщений ответа.
Request (Заголовки запроса): эти поля заголовка применимы только для сообщений запроса.
Response (Заголовки ответа): эти поля заголовка применимы только для ответных сообщений.
Entity (Заголовки сущности): эти поля заголовка определяют метаинформацию о теле объекта

Все вышеупомянутые заголовки следуют одному и тому же общему формату, и каждое поле заголовка состоит из имени, за которым следует двоеточие (:) и значение поля, как показано ниже:

имя-поля: [значение-поля]

Ниже приведены примеры различных полей заголовка:

Host: suip.biz
User-Agent: Chrome
Accept: */*

Date: Tue, 03 Nov 2020 06:15:50 GMT
Server: Apache/2.4.46 (Unix) PHP/7.4.12
Vary: Accept-Encoding
X-Powered-By: PHP/7.4.12
X-Frame-Options: SAMEORIGIN
Content-Type: text/html; charset=UTF-8
X-Varnish: 328517
Age: 0
Via: 1.1 varnish (Varnish/6.5)
Accept-Ranges: bytes
Connection: keep-alive

Тело сообщения

Часть сообщения, которое называется телом, является необязательной для HTTP-сообщения, но если она доступна, она используется для переноса тела объекта, связанного с запросом или ответом. Если тело объекта присутствует, то обычно строки заголовков Content-Type и Content-Length указывают природу тела сообщения.

Тело сообщения — это та часть, которая содержит фактические данные HTTP-запроса (сюда же относятся данные, передаваемые через веб-формы и выгружаемые файлы) и данные HTTP-ответа от сервера (включая HTML код, файлы, изображения и т. д.). Ниже приводится простое содержание тела сообщения (ответ):

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Как посмотреть HTTP заголовки

Как в веб-браузере увидеть HTTP заголовки

Это самый простой способ, доступный в любой операционной системе.

Нажмите в веб-браузере F12 и откройте интересующую вас страницу. Перейдите на вкладку Network (сеть) и выберите интересующее вас подключение.

Google Chrome/Chromium:

Firefox:

Вначале идут Заголовки ответа (Response Headers), а затем Заголовки запроса (Request Headers), хотя, конечно же, вначале отправляется запрос и его заголовки, а затем приходит ответ.

Это удобный метод, причём вам не нужно беспокоиться о HTTPS протоколе — поскольку веб-браузер является конечным адресатом, то он может показывать уже расшифрованные данные.

Как в cURL посмотреть HTTP заголовки

Для cURL есть опции -I, -v и -i, которые делают так, что эта утилита показывает HTTP заголовки.

Разница в том, что опция -I означает использовать метод HEAD, то есть в реальности кроме HTTP заголовков ничего не будет прислано. А опция -v делает вывод более вербальным, в результате в него включаются и заголовки. Но если вы отправляете запрос по HTTPS протоколу, то с опцией -v также будут показаны данные, относящиеся к TLS рукопожатию — они не имеют отношения к HTTP заголовкам. Ещё нужно знать, что опция -I показывает только заголовки ответа, а опция -v показывает и Заголовки запроса и Заголовки ответа.

Опция -i также показывает только заголовки ответа, не показывает TLS рукопожатие, но зато показывает всё тело ответа.

Пример использования метода HEAD:

curl -I https://suip.biz/ru/ -A 'Chrome'

Здесь «HTTP/1.1 200 OK» это строка статуса, а всё остальное — поля HTTP заголовка.

Пример вербального вывода:

curl -v https://suip.biz/ru/ -A 'Chrome' > /dev/null

Отправленные на веб сервер заголовки имеют в начале символ >, а полученные с веб-сервера строки начинаются на <.

Синей рамкой выделены стартовые строки (строка запроса и строка статуса), а красным HTTP заголовки.

Пример вывода заголовков вместе с телом сообщения:

curl -i https://suip.biz/ru/ -A 'Chrome'

С опцией -i HTTP заголовки выводятся в стандартный вывод, а с опцией -v заголовки выводятся в вывод ошибок.

HTTP заголовки в Wireshark (только для протокола HTTP, без HTTPS)

До сих пор мы программа, которая показывает HTTP заголовки и которая отправляет запросы и принимает ответы совпадали, поэтому даже при использовании протокола HTTPS мы видели расшифрованные данные. Но программа Wireshark не может расшифровывать протокол HTTPS, поэтому в ней можно просмотреть только заголовки для незашифрованного трафика.

Для поиска HTTP сообщений используйте фильтр

http

Заголовки запросов и ответов смотрите в «Hypertext Transfer Protocol»:

Преимущества Wireshark в том, что кроме просмотра HTTP заголовков, вы можете использовать гибкую и мощную систему фильтров для поиска по полям заголовка. Подробности смотрите в справочной статье «Фильтры Wireshark».

HTTP заголовки в Burp Suite

Программа Burp Suite содержит прокси специально для просмотра заголовков. Более того, в программе имеются функции по модификации заголовков и другого содержимого на лету. Но Burp Suite это профессиональная программа, требующая изучения.

Burp Suite умеет работать с запросами по HTTPS, но для этого требуется настройка SSL сертификатов в веб-браузере.

Смотрите близкую по теме статью: Как отобразить данные POST с cURL.

Запросы

HTTP-клиент отправляет HTTP-запрос на сервер в форме сообщения запроса («request message»), которое включает в себя следующие элементы:

Строка запроса
Ноль или более полей заголовка (общие заголовки, заголовки запроса и заголовки сущности), за которыми следует символ CRLF
Пустая строка (то есть строка, в которой ничего не предшествует CRLF), указывающая конец полей заголовка
Необязательно тело сообщения

В следующем разделе объясняется каждый из объектов, используемых в сообщении HTTP.

Строка запроса

Строка запроса начинается с токена метода, за которым следует URI и версия протокола, и заканчивается CRLF. Элементы разделяются пробелами.

Метод URI Версия HTTP

Давайте обсудим каждую часть, упомянутую в строке запроса.

Метод запроса

Метод HTTP (англ. HTTP Method) — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.

Метод запроса указывает метод, который должен быть выполнен для ресурса, идентифицированного данным URI. Метод чувствителен к регистру, и его всегда следует указывать прописными буквы. Ниже приведены поддерживаемые методы в HTTP/1.1.

Сервер может использовать любые методы, не существует обязательных методов для сервера или клиента. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD, часто применяется метод POST.

Метод	Описание
GET	Используется для запроса содержимого указанного ресурса. С помощью метода GET можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса. Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»: GET /path/resource?param1=value1&param2=value2 HTTP/1.1 Согласно стандарту HTTP, запросы типа GET считаются идемпотентными Кроме обычного метода GET, различают ещё Условный GET — содержит заголовки If-Modified-Since, If-Match, If-Range и подобные; Частичный GET — содержит в запросе Range. Порядок выполнения подобных запросов определён стандартами отдельно.
HEAD	Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения. Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше — копия ресурса помечается как устаревшая.
POST	Применяется для передачи пользовательских данных заданному ресурсу, в том числе выгрузки файлов на веб-сервер. Например, в блогах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом POST и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода POST обычно загружаются файлы на сервер. В отличие от метода GET, метод POST не считается идемпотентным, то есть многократное повторение одних и тех же запросов POST может возвращать разные результаты (например, после каждой отправки комментария будет появляться очередная копия этого комментария). При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location. Сообщение ответа сервера на выполнение метода POST не кэшируется.
PUT	Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурс, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented). Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу. Сообщения ответов сервера на метод PUT не кэшируются.
DELETE	Удаляет указанный ресурс.
CONNECT	Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищённого SSL-соединения через нешифрованный прокси.
OPTIONS	Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях. Предполагается, что запрос клиента может содержать тело сообщения для указания интересующих его сведений. Формат тела и порядок работы с ним в настоящий момент не определён; сервер пока должен его игнорировать. Аналогичная ситуация и с телом в ответе сервера. Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «». Запросы «OPTIONS HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1. Результат выполнения этого метода не кэшируется.
TRACE	Возвращает полученный запрос так, что клиент может увидеть, какую информацию промежуточные серверы добавляют или изменяют в запросе.
PATCH	Аналогично PUT, но применяется только к фрагменту ресурса.

Далеко не все веб-серверы придерживаются описанного поведения, многие обрабатывают в соответствии с написанным только GET, POST и HEAD, а все остальные методы, в том числе несуществующие, обрабатывают как GET.

URI

URI — это Uniform Resource Identifier, то есть универсальный идентификатор ресурса, который определяет ресурс, к которому следует применить запрос. Ниже приведены наиболее часто используемые формы для указания URI:

Метод и описание
Звёздочка * используется, когда HTTP-запрос применяется не к определённому ресурсу, а к самому серверу, и разрешён только в том случае, если используемый метод не обязательно применим к ресурсу. Например: *OPTIONS HTTP/1.1**
Абсолютный URI используется при отправке HTTP-запроса к прокси. Прокси-сервер запрашивается для пересылки запроса или обслуживания его из действительного кеша и возврата ответа. Например: GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
Наиболее распространённая форма URI — это та, которая используется для идентификации ресурса на исходном сервере или шлюзе. Например, клиент, желающий получить указанный выше ресурс непосредственно с исходного сервера, создаст TCP-соединение с портом 80 хоста «www.w3.org» и отправит строки: GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org Обратите внимание, что путь не может быть пустым; если в исходном URI ничего нет, он ДОЛЖЕН быть указан как "/" (корень сервера)

Метод и описание

Звёздочка * используется, когда HTTP-запрос применяется не к определённому ресурсу, а к самому серверу, и разрешён только в том случае, если используемый метод не обязательно применим к ресурсу. Например:

OPTIONS * HTTP/1.1

Абсолютный URI используется при отправке HTTP-запроса к прокси. Прокси-сервер запрашивается для пересылки запроса или обслуживания его из действительного кеша и возврата ответа. Например:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

Наиболее распространённая форма URI — это та, которая используется для идентификации ресурса на исходном сервере или шлюзе. Например, клиент, желающий получить указанный выше ресурс непосредственно с исходного сервера, создаст TCP-соединение с портом 80 хоста «www.w3.org» и отправит строки:

GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org

Обратите внимание, что путь не может быть пустым; если в исходном URI ничего нет, он ДОЛЖЕН быть указан как "/" (корень сервера)

Поля заголовка запроса

Мы изучим общие заголовки и заголовки сущности в отдельной главе, когда будем рассматривать поля заголовка HTTP. А пока давайте проверим, что такое поля заголовка запроса.

Поля заголовка запроса позволяют клиенту передавать на сервер дополнительную информацию о запросе и о самом клиенте. Эти поля действуют как модификаторы запроса. Доступны следующие важные поля заголовка запроса, которые можно использовать в зависимости от необходимости.

Accept-Charset
Accept-Encoding
Accept-Language
Authorization
Expect
From
Host
If-Match
If-Modified-Since
If-None-Match
If-Range
If-Unmodified-Since
Max-Forwards
Proxy-Authorization
Range
Referer
TE
User-Agent

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

Примеры сообщений запроса

Теперь давайте соберём все это вместе, чтобы сформировать HTTP-запрос для получения страницы robots.txt с веб-сервера, запущенного на suay.ru.

GET /robots.txt HTTP/2
Host: suay.ru
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: _ga=............................
Upgrade-Insecure-Requests: 1
If-Modified-Since: Tue, 02 Jun 2020 09:00:16 GMT
If-None-Match: "966122f-10f-5a71623d78800"
Cache-Control: max-age=0

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

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

licenseID=string&content=string&/paramsXML=string

Здесь указанный URL /cgi-bin/process.cgi будет использоваться для обработки переданных данных, и, соответственно, ответ будет возвращён с него. Здесь тип содержимого сообщает серверу, что переданные данные представляют собой простые данные веб-формы, а длина будет фактической длиной данных, помещенных в тело сообщения.

В следующем примере показано, как передать XML на свой веб-сервер:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Content-Type: text/xml; charset=utf-8
Content-Length: length
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://something.com/">string</string>

Ответы

После получения и интерпретации сообщения запроса сервер отвечает сообщением ответа HTTP, его структура:

Строка состояния
Ноль или более полей заголовка (общие заголовки, заголовки ответа и заголовки сущности), за которыми следует символ CRLF
Пустая строка (т.е. строка, в которой ничего не предшествует CRLF), указывающая на конец полей заголовка
Необязательно тело сообщения

В следующем разделе будет объяснен каждый из объектов, используемых в сообщении HTTP.

Строка состояния сообщения

Строка состояния, состоящая из версии протокола, за которым следует числовой код состояния и связанная с ним текстовая фраза. Элементы разделяются пробелами.

HTTP-версия Код состояния Причина-фраза

Давайте обсудим каждую часть, упомянутую в статусной строке.

Версия HTTP

Сервер, поддерживающий HTTP версии 1.1, вернет следующую информацию о версии:

HTTP/1.1

Код состояния

Клиент узнаёт по коду ответа о результатах его запроса и определяет, какие действия ему предпринимать дальше. Набор кодов состояния является стандартом, и они описаны в соответствующих документах RFC. Введение новых кодов должно производиться только после согласования с IETF. Клиент может не знать все коды состояния, но он обязан отреагировать в соответствии с классом кода.

В настоящее время выделено пять классов кодов состояния.

Элемент Код состояния представляет собой трехзначное целое число, где первая цифра код состояния определяет класс ответа, а последние две цифры уточняют его. Первая цифра имеет 5 значений:

Код	Класс	Назначение
`1xx`	Информационный (англ. informational)	Информирование о процессе передачи. В HTTP/1.0 — сообщения с такими кодами должны игнорироваться. В HTTP/1.1 — клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-серверы подобные сообщения должны отправлять дальше от сервера к клиенту.
`2xx`	Успех (англ. Success)	Информирование о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса, сервер может ещё передать заголовки и тело сообщения.
`3xx`	Перенаправление (англ. Redirection)	Сообщает клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов `301`, `302`, `303`, `305` и `307` относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке `Location`. При этом допускается использование фрагментов в целевом URI.
`4xx`	Ошибка клиента (англ. Client Error)	Указание ошибок со стороны клиента. При использовании всех методов, кроме `HEAD`, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
`5xx`	Ошибка сервера (англ. Server Error)	Информирование о случаях неудачного выполнения операции по вине сервера. Для всех ситуаций, кроме использования метода `HEAD`, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

Коды состояния HTTP являются расширяемыми, и приложения HTTP не обязаны понимать значение всех зарегистрированных кодов состояния.

Поля заголовка ответа

Мы изучим общие заголовки и заголовки сущности в отдельной главе, когда будем рассматривать поля заголовка HTTP. А пока давайте проверим, что такое поля заголовка ответа.

Поля заголовка ответа позволяют серверу передавать дополнительную информацию об ответе, которую нельзя поместить в строку состояния. Эти поля заголовка предоставляют информацию о сервере и о дальнейшем доступе к ресурсу, URI которого мы указали.

Accept-Ranges
Age
ETag
Location
Proxy-Authenticate
Retry-After
Server
Vary
WWW-Authenticate

Вы можете ввести новые поля, если собираетесь написать свои собственные веб-клиент и сервер.

Примеры сообщений ответа

Теперь давайте соберём все это вместе, чтобы сформировать HTTP-ответ на запрос на получение страницы hello.htm с веб-сервера, запущенного на site.com.

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Ниже приведён пример сообщения HTTP-ответа, показывающего состояние ошибки, когда веб-сервер не может найти запрошенную страницу:

HTTP/1.1 404 Not Found
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Connection: Closed
Content-Type: text/html; charset=iso-8859-1
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>404 Not Found</title>
</head>
<body>
   <h1>Not Found</h1>
   <p>The requested URL /t.html was not found on this server.</p>
</body>
</html>

Ниже приведён пример сообщения HTTP-ответа, показывающего состояние ошибки, когда веб-сервер обнаружил неправильную версию HTTP в данном HTTP-запросе:

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: Closed
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Методы

Набор популярных методов для HTTP/1.1 определён в сводной таблице выше, и этот набор может быть расширен в зависимости от требований. В этих именах методов учитывается регистр, и они должны использоваться в верхнем регистре.

Напомним остновные HTTP методы:

Метод	Описание
GET	Метод GET используется для получения информации с заданного сервера с использованием заданного URI. Запросы, использующие GET, должны только извлекать данные и не должны иметь никакого другого влияния на данные.
HEAD	То же, что GET, но передаёт только строку состояния и раздел заголовка.
POST	Запрос POST используется для отправки данных на сервер и загрузки файлов и прочего с использованием HTML-форм.
PUT	Замените все текущие представления целевого ресурса загруженным контентом.
DELETE	Удалите все текущие представления целевого ресурса, заданные URI.
CONNECT	Установите туннель к серверу, идентифицированному данным URI.
OPTIONS	В ответе описывает варианты коммуникации для целевого ресурса (перечисляет поддерживаемые методы).
TRACE	Выполняет тестовое обратное сообщение.

Метод GET

Запрос GET извлекает данные с веб-сервера, указывая параметры в части URL-адреса запроса. Это основной метод, используемый для поиска документов. Ниже приведён простой пример, в котором для получения hello.htm используется метод GET:

GET /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

За ним следует ответ сервера на указанный выше запрос GET:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Метод HEAD

Метод HEAD функционально похож на GET, за исключением того, что сервер отвечает строкой ответа и заголовками, но без тела объекта. Ниже приведён простой пример, который использует метод HEAD для получения информации заголовка о hello.htm:

HEAD /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

За ним следует ответ сервера на указанный выше запрос GET:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

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

Метод POST

Метод POST используется, когда вы хотите отправить некоторые данные на сервер, например обновление файла, данные формы и т. д. Ниже приведён простой пример, в котором используется метод POST для отправки данных формы на сервер, которые будут обработаны process.cgi и затем будет возвращён ответ:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://something.com/">string</string>

Серверный скрипт process.cgi обрабатывает переданные данные и отправляет следующий ответ:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>

Метод PUT

Метод PUT используется, чтобы запросить сервер сохранить включённое тело объекта в месте, указанном по данному URL-адресу. Следующий пример запрашивает сервер для сохранения заданного тела объекта в hello.htm в корне сервера:

PUT /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Accept-Language: en-us
Connection: Keep-Alive
Content-type: text/html
Content-Length: 182

<html>
<body>
<h1>Hello, World!</h1>
</body>
</html>

Сервер сохранит данное тело объекта в файле hello.htm и отправит клиенту следующий ответ:

HTTP/1.1 201 Created
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>The file was created.</h1>
</body>
</html>

Метод DELETE

Метод DELETE используется для запроса сервера на удаление файла в расположении, указанном данным URL. В следующем примере сервер запрашивает удаление указанного файла hello.htm в корне сервера:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.site.com
Accept-Language: en-us
Connection: Keep-Alive

Сервер удалит указанный файл hello.htm и отправит клиенту следующий ответ:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

Метод CONNECT

Метод CONNECT используется клиентом для установления сетевого подключения к веб-серверу через HTTP. В следующем примере запрашивается соединение с веб-сервером, работающим на хосте site.com:

ONNECT www.site.com HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Устанавливается соединение с сервером, и клиенту отправляется следующий ответ:

HTTP/1.1 200 Connection established
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)

Метод OPTIONS

Метод OPTIONS используется клиентом, чтобы узнать, какие методы HTTP и другие параметры поддерживаются веб-сервером. Клиент может указать URL-адрес для метода OPTIONS или звёздочку (*) для ссылки на весь сервер. В следующем примере запрашивается список методов, поддерживаемых веб-сервером на сайте site.com:

OPTIONS * HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Сервер отправит информацию на основе текущей конфигурации сервера, например:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Allow: GET,HEAD,POST,OPTIONS,TRACE
Content-Type: httpd/unix-directory

Метод TRACE

Метод TRACE используется для передачи содержимого HTTP-запроса обратно запрашивающей стороне, что может быть использовано для целей отладки во время разработки. В следующем примере показано использование метода TRACE:

TRACE / HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Сервер отправит следующее сообщение в ответ на вышеуказанный запрос:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Type: message/http
Content-Length: 39
Connection: Closed

TRACE / HTTP/1.1
Host: www.site.com
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Как отправить HTTP запрос методом OPTIONS и другими методами

Программа cURL позволяет отправить HTTP запрос любым методом, в том числе OPTIONS, HEAD, POST, PUT, DELETE, CONNECT, TRACE, PATCH и даже любым другим произвольным именем.

Для этого в cURL используется опция -X. Эта опция в различных протоколах позволяет установить команду для выполнения вместо стандартной, а в протоколе HTTP позволяет указать метод запроса.

OPTIONS /путь

С cURL можно отправить запрос OPTIONS примерно так:

curl -i -X OPTIONS http://example.org/path

Также можно использовать -v вместо -i, чтобы видеть больше вывода.

Пример с опцией -v, при которой заголовки отправляются в вывод ошибок, при этом можно уничтожить стандартный вывод, чтобы он не загромождал экран:

curl -v -s -X OPTIONS 87.236.16.208 > /dev/null

На скриншоте вы можете увидеть строку со списком поддерживаемых опций:

< Allow: POST,OPTIONS,GET,HEAD

Это означает, что запрос выполнен правильно.

OPTIONS *

Чтобы отправить простой * (вместо пути, смотрите RFC 7231) с методом OPTIONS, вы можете запустить команду примерно так:

curl -v -s --request-target "*" -X OPTIONS 87.236.16.208 > /dev/null

Как отправить HTTP запрос с произвольным методом

Используя опцию -X можно отправить запрос с любым именем, например:

curl -v -s -X HACKWARE 87.236.16.208 > /dev/null

Строка в которой сказано, что «Не реализовано» и код статуса 501 — именно это и ожидалось:

< HTTP/1.1 501 Not Implemented

Опция -X в cURL

Опция -X, или длинная версия —request <КОМАНДА> в cURL работает по-разному в зависимости от протокола, с которым она используется.

С протоколом HTTP

Задаёт настраиваемый метод запроса для использования при взаимодействии с HTTP-сервером. Указанный метод запроса будет использоваться вместо метода, который в противном случае использовался (по умолчанию GET). Прочтите спецификацию HTTP 1.1 для получения подробностей и пояснений. Общие дополнительные HTTP-запросы включают PUT и DELETE, но связанные технологии, такие как WebDAV, предлагают PROPFIND, COPY, MOVE и другие.

Обычно эта опция вам не нужна. Все виды запросов GET, HEAD, POST и PUT скорее вызываются с помощью специальных параметров командной строки.

Эта опция изменяет только фактическое слово, используемое в HTTP-запросе, но не влияет на поведение curl. Так, например, если вы хотите сделать правильный запрос HEAD, использования -X HEAD будет недостаточно. Вам нужно использовать параметр -I, —head.

Строка метода, которую вы установили с помощью -X, —request, будет использоваться для всех запросов, что, если вы, например, используете -L, —location, может вызвать непреднамеренные побочные эффекты, когда curl не изменяет метод запроса в соответствии с HTTP 30x коды ответов — и тому подобное.

С протоколом FTP

Задаёт настраиваемую команду FTP, которая будет использоваться вместо LIST при составлении списков файлов с помощью FTP.

С протоколом POP3

Задаёт настраиваемую команду POP3 для использования вместо LIST или RETR.

С протоколом IMAP

Задаёт настраиваемую команду IMAP для использования вместо LIST.

С протоколом SMTP

Задаёт настраиваемую команду SMTP для использования вместо HELP или VRFY.

Если эта опция используется несколько раз, будет использован последняя.

Коды состояния

Элемент код статуса в ответе сервера представляет собой трёхзначное целое число, где первая цифра кода статуса определяет класс ответа, а последние две цифры не имеют роли категоризации. Первая цифра имеет 5 значений:

Код	Описание
1	1xx: Информационный Это означает, что запрос получен и процесс продолжается.
2	2xx: Успех Это означает, что действие было успешно получено, понято и принято.
3	3xx: Перенаправление Это означает, что для выполнения запроса необходимо предпринять дальнейшие действия.
4	4xx: Ошибка клиента Это означает, что запрос содержит неверный синтаксис или не может быть выполнен.
5	5xx: Ошибка сервера Серверу не удалось выполнить явно действительный запрос

Коды состояния HTTP являются расширяемыми, и приложения HTTP не обязаны понимать значение всех зарегистрированных кодов состояния. Ниже приведён список всех кодов состояния.

1xx: Informational (информационные):
100 Continue («продолжай»);
101 Switching Protocols («переключение протоколов»);
102 Processing («идёт обработка»);
103 Early Hints («ранняя метаинформация»);
2xx: Success (успешно):
200 OK («хорошо»);
201 Created («создано»);
202 Accepted («принято»);
203 Non-Authoritative Information («информация не авторитетна»);
204 No Content («нет содержимого»);
205 Reset Content («сбросить содержимое»);
206 Partial Content («частичное содержимое»);
207 Multi-Status («многостатусный»);
208 Already Reported («уже сообщалось»);
226 IM Used («использовано IM»).
3xx: Redirection (перенаправление):
300 Multiple Choices («множество выборов»);
301 Moved Permanently («перемещено навсегда»);
302 Moved Temporarily («перемещено временно»);
302 Found («найдено»);
303 See Other («смотреть другое»);
304 Not Modified («не изменялось»);
305 Use Proxy («использовать прокси»);
306 — зарезервировано (код использовался только в ранних спецификациях);
307 Temporary Redirect («временное перенаправление»);
308 Permanent Redirect («постоянное перенаправление»).
4xx: Client Error (ошибка клиента):
400 Bad Request («плохой, неверный запрос»);
401 Unauthorized («не авторизован (не представился)»);
402 Payment Required («необходима оплата»);
403 Forbidden («запрещено (не уполномочен)»);
404 Not Found («не найдено»);
405 Method Not Allowed («метод не поддерживается»);
406 Not Acceptable («неприемлемо»);
407 Proxy Authentication Required («необходима аутентификация прокси»);
408 Request Timeout («истекло время ожидания»);
409 Conflict («конфликт»);
410 Gone («удалён»);
411 Length Required («необходима длина»);
412 Precondition Failed («условие ложно»);
413 Payload Too Large («полезная нагрузка слишком велика»);
414 URI Too Long («URI слишком длинный»);
415 Unsupported Media Type («неподдерживаемый тип данных»);
416 Range Not Satisfiable («диапазон не достижим»);
417 Expectation Failed («ожидание не удалось»);
418 I’m a teapot («я — чайник»);
419 Authentication Timeout (not in RFC 2616) («обычно ошибка проверки CSRF»);
421 Misdirected Request;
422 Unprocessable Entity («необрабатываемый экземпляр»);
423 Locked («заблокировано»);
424 Failed Dependency («невыполненная зависимость»);
425 Too Early («слишком рано»);
426 Upgrade Required («необходимо обновление»);
428 Precondition Required («необходимо предусловие»);
429 Too Many Requests («слишком много запросов»);
431 Request Header Fields Too Large («поля заголовка запроса слишком большие»);
449 Retry With («повторить с»);
451 Unavailable For Legal Reasons («недоступно по юридическим причинам»).
499 Client Closed Request (клиент закрыл соединение);
5xx: Server Error (ошибка сервера):
500 Internal Server Error («внутренняя ошибка сервера»);
501 Not Implemented («не реализовано»);
502 Bad Gateway («плохой, ошибочный шлюз»);
503 Service Unavailable («сервис недоступен»);
504 Gateway Timeout («шлюз не отвечает»);
505 HTTP Version Not Supported («версия HTTP не поддерживается»);
506 Variant Also Negotiates («вариант тоже проводит согласование»);
507 Insufficient Storage («переполнение хранилища»);
508 Loop Detected («обнаружено бесконечное перенаправление»);
509 Bandwidth Limit Exceeded («исчерпана пропускная ширина канала»);
510 Not Extended («не расширено»);
511 Network Authentication Required («требуется сетевая аутентификация»);
520 Unknown Error («неизвестная ошибка»);
521 Web Server Is Down («веб-сервер не работает»);
522 Connection Timed Out («соединение не отвечает»);
523 Origin Is Unreachable («источник недоступен»);
524 A Timeout Occurred («время ожидания истекло»);
525 SSL Handshake Failed («квитирование SSL не удалось»);
526 Invalid SSL Certificate («недействительный сертификат SSL»).

1xx: Информационные

В этот класс выделены коды, информирующие о процессе передачи. При работе через протокол версии 1.0 сообщения с такими кодами должны игнорироваться. В версии 1.1 клиент должен быть готов принять этот класс сообщений как обычный ответ, но серверу отправлять что-либо не нужно. Сами сообщения от сервера содержат только стартовую строку ответа и, если требуется, несколько специфичных для ответа полей заголовка. Прокси-сервера подобные сообщения должны отправлять дальше от сервера к клиенту.

100 Continue — сервер удовлетворён начальными сведениями о запросе, клиент может продолжать пересылать заголовки. Появился в HTTP/1.1.
101 Switching Protocols — сервер выполняет требование клиента и переключает протоколы в соответствии с указанием, данным в поле заголовка Upgrade. Сервер отправляет заголовок ответа Upgrade, указывая протокол, на который он переключился. Появился в HTTP/1.1.
102 Processing — запрос принят, но на его обработку понадобится длительное время. Используется сервером, чтобы клиент не разорвал соединение из-за превышения времени ожидания. Клиент при получении такого ответа должен сбросить таймер и дожидаться следующей команды в обычном режиме. Появился в WebDAV.
103 Early Hints — используется для раннего возврата части заголовков, когда заголовки полного ответа не могут быть быстро сформированы.

2xx: Успех

Сообщения данного класса информируют о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса сервер может ещё передать заголовки и тело сообщения.

200 OK — успешный запрос. Если клиентом были запрошены какие-либо данные, то они находятся в заголовке и/или теле сообщения. Появился в HTTP/1.0.
201 Created — в результате успешного выполнения запроса был создан новый ресурс. Сервер может указать адреса (их может быть несколько) созданного ресурса в теле ответа, при этом предпочтительный адрес указывается в заголовке Location. Серверу рекомендуется указывать в теле ответа характеристики созданного ресурса и его адреса, формат тела ответа определяется заголовком Content-Type. При обработке запроса новый ресурс должен быть создан до отправки ответа клиенту, иначе следует использовать ответ с кодом 202. Появился в HTTP/1.0.
202 Accepted — запрос был принят на обработку, но она не завершена. Клиенту не обязательно дожидаться окончательной передачи сообщения, так как может быть начат очень долгий процесс. Появился в HTTP/1.0.
203 Non-Authoritative Information — аналогично ответу 200, но в этом случае передаваемая информация была взята не из первичного источника (резервной копии, другого сервера и т. д.) и поэтому может быть неактуальной. Появился в HTTP/1.1.
204 No Content — сервер успешно обработал запрос, но в ответе были переданы только заголовки без тела сообщения. Клиент не должен обновлять содержимое документа, но может применить к нему полученные метаданные. Появился в HTTP/1.0.
205 Reset Content — сервер обязывает клиента сбросить введённые пользователем данные. Тела сообщения сервер при этом не передаёт и документ обновлять не обязательно. Появился в HTTP/1.1.
206 Partial Content — сервер удачно выполнил частичный GET-запрос, возвратив только часть сообщения. В заголовке Content-Range сервер указывает байтовые диапазоны содержимого. Особое внимание при работе с подобными ответами следует уделить кэшированию. Появился в HTTP/1.1.
207 Multi-Status — сервер передаёт результаты выполнения сразу нескольких независимых операций. Они помещаются в само тело сообщения в виде XML-документа с объектом multistatus. Не рекомендуется размещать в этом объекте статусы из серии 1xx из-за бессмысленности и избыточности. Появился в WebDAV.
208 Already Reported — члены привязки DAV уже были перечислены в предыдущей части (multistatus) ответа и не включаются снова.
226 IM Used — заголовок A-IM от клиента был успешно принят и сервер возвращает содержимое с учётом указанных параметров. Введено в RFC 3229 для дополнения протокола HTTP поддержкой дельта-кодирования.

3xx: Перенаправление

Коды этого класса сообщают клиенту, что для успешного выполнения операции необходимо сделать другой запрос, как правило, по другому URI. Из данного класса пять кодов 301, 302, 303, 305 и 307 относятся непосредственно к перенаправлениям. Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке Location. При этом допускается использование фрагментов в целевом URI.

По последним стандартам клиент может производить перенаправление без запроса пользователя только если второй ресурс будет запрашиваться методом GET или HEAD. В предыдущих спецификациях говорилось, что для избежания круговых переходов пользователя следует спрашивать после 5-го подряд перенаправления. При всех перенаправлениях, если метод запроса был не HEAD, то в тело ответа следует включить короткое гипертекстовое сообщение с целевым адресом, чтобы в случае ошибки пользователь смог сам произвести переход.

Разработчики HTTP отмечают, что многие клиенты при перенаправлениях с кодами 301 и 302 ошибочно применяют метод GET ко второму ресурсу, несмотря на то, что к первому запрос был с иным методом (чаще всего PUT). Чтобы избежать недоразумений, в версии HTTP/1.1 были введены коды 303 и 307 и их рекомендовано использовать вместо 302. Изменять метод нужно только если сервер ответил 303. В остальных случаях следующий запрос производить с исходным методом.

Поведение клиентов при различных перенаправлениях описано в таблице:

Статус ответа	Кэширование	Если метод не GET или HEAD
`301 Moved Permanently`	Можно как обычно.	Спросить у пользователя подтверждения и запросить другой ресурс исходным методом.
`307 Temporary Redirect`	Можно только если указан заголовок `Cache-Control` или `Expires`.
`302 Found` (HTTP/1.1) `302 Moved Temporarily` (HTTP/1.0)
`303 See Other`	Нельзя.	Перейти автоматически, но уже методом `GET`.

300 Multiple Choices — по указанному URI существует несколько вариантов предоставления ресурса по типу MIME, по языку или по другим характеристикам. Сервер передаёт с сообщением список альтернатив, давая возможность сделать выбор клиенту автоматически или пользователю. Появился в HTTP/1.0.
301 Moved Permanently — запрошенный документ был окончательно перенесен на новый URI, указанный в поле Location заголовка. Некоторые клиенты некорректно ведут себя при обработке данного кода. Появился в HTTP/1.0.
302 Found, 302 Moved Temporarily — запрошенный документ временно доступен по другому URI, указанному в заголовке в поле Location. Этот код может быть использован, например, при управляемом сервером согласовании содержимого. Некоторые клиенты некорректно ведут себя при обработке данного кода. Введено в HTTP/1.0.
303 See Other — документ по запрошенному URI нужно запросить по адресу в поле Location заголовка с использованием метода GET несмотря даже на то, что первый запрашивался иным методом. Этот код был введён вместе с кодом 307 для избежания неоднозначности, чтобы сервер был уверен, что следующий ресурс будет запрошен методом GET. Например, на веб-странице есть поле ввода текста для быстрого перехода и поиска. После ввода данных браузер делает запрос методом POST, включая в тело сообщения введённый текст. Если обнаружен документ с введённым названием, то сервер отвечает кодом 303, указав в заголовке Location его постоянный адрес. Тогда браузер гарантировано его запросит методом GET для получения содержимого. В противном случае сервер просто вернёт клиенту страницу с результатами поиска. Введено в HTTP/1.1.
304 Not Modified — сервер возвращает такой код, если клиент запросил документ методом GET, использовал заголовок If-Modified-Since или If-None-Match и документ не изменился с указанного момента. При этом сообщение сервера не должно содержать тела. Появился в HTTP/1.0.
305 Use Proxy — запрос к запрашиваемому ресурсу должен осуществляться через прокси-сервер, URI которого указан в поле Location заголовка. Данный код ответа могут использовать только исходные HTTP-сервера (не прокси). Введено в HTTP/1.1.
306 (зарезервировано) — использовавшийся раньше код ответа, в настоящий момент зарезервирован. Упомянут в RFC 2616 (обновление HTTP/1.1).
307 Temporary Redirect — запрашиваемый ресурс на короткое время доступен по другому URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместе с 303 вместо 302-го для избежания неоднозначности. Введено в RFC 2616 (обновление HTTP/1.1).
308 Permanent Redirect — запрашиваемый ресурс был окончательно перенесен на новый URI, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается. Например, POST запрос должен быть отправлен по новому URI тем же методом POST. Этот код был введён вместо 301-го для избежания неоднозначности. Введено в RFC 7238 (RFC 7538).

4xx: Ошибка клиента

Класс кодов 4xx предназначен для указания ошибок со стороны клиента. При использовании всех методов, кроме HEAD, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.

400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку. Появился в HTTP/1.0.
401 Unauthorized — для доступа к запрашиваемому ресурсу требуется аутентификация. В заголовке ответ должен содержать поле WWW-Authenticate с перечнем условий аутентификации. Иными словами, для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization с требуемыми для аутентификации данными. Если запрос уже включает данные для авторизации, ответ 401 означает, что в авторизации с ними отказано.
402 Payment Required — предполагается использовать в будущем. В настоящий момент не используется. Этот код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний. Имеется в виду, что эта ошибка не будет выдана хостинговым провайдером в случае просроченной оплаты его услуг. Зарезервирован, начиная с HTTP/1.1.

403 Forbidden — сервер понял запрос, но он отказывается его выполнять из-за ограничений в доступе для клиента к указанному ресурсу. Иными словами, клиент не уполномочен совершать операции с запрошенным ресурсом. Если для доступа к ресурсу требуется аутентификация средствами HTTP, то сервер вернёт ответ 401, или 407 при использовании прокси. В противном случае ограничения были заданы администратором сервера или разработчиком веб-приложения и могут быть любыми в зависимости от возможностей используемого программного обеспечения. В любом случае серверу следует сообщить причины отказа в обработке запроса. Наиболее вероятными причинами ограничения может послужить попытка доступа к системным ресурсам веб-сервера (например, файлам .htaccess или .htpasswd) или к файлам, доступ к которым был закрыт с помощью конфигурационных файлов, требование аутентификации не средствами HTTP, например, для доступа к системе управления содержимым или разделу для зарегистрированных пользователей либо сервер не удовлетворён IP-адресом клиента, например, при блокировках. Появился в HTTP/1.0.
404 Not Found — самая распространённая ошибка при пользовании Интернетом, основная причина — ошибка в написании адреса Web-страницы. Сервер понял запрос, но не нашёл соответствующего ресурса по указанному URL. Если серверу известно, что по этому адресу был документ, то ему желательно использовать код 410. Ответ 404 может использоваться вместо 403, если требуется тщательно скрыть от посторонних глаз определённые ресурсы. Появился в HTTP/1.0.
405 Method Not Allowed — указанный клиентом метод нельзя применить к текущему ресурсу. В ответе сервер должен указать доступные методы в заголовке Allow, разделив их запятой. Эту ошибку сервер должен возвращать, если метод ему известен, но он не применим именно к указанному в запросе ресурсу, если же указанный метод не применим на всём сервере, то клиенту нужно вернуть код 501 (Not Implemented). Появился в HTTP/1.1.
406 Not Acceptable — запрошенный URI не может удовлетворить переданным в заголовке характеристикам. Если метод был не HEAD, то сервер должен вернуть список допустимых характеристик для данного ресурса. Появился в HTTP/1.1.
407 Proxy Authentication Required — ответ аналогичен коду 401 за исключением того, что аутентификация производится для прокси-сервера. Механизм аналогичен идентификации на исходном сервере. Появился в HTTP/1.1.
408 Request Timeout — время ожидания сервером передачи от клиента истекло. Клиент может повторить аналогичный предыдущему запрос в любое время. Например, такая ситуация может возникнуть при загрузке на сервер объёмного файла методом POST или PUT. В какой-то момент передачи источник данных перестал отвечать, например, из-за повреждения компакт-диска или потери связи с другим компьютером в локальной сети. Пока клиент ничего не передаёт, ожидая от него ответа, соединение с сервером держится. Через некоторое время сервер может закрыть соединение со своей стороны, чтобы дать возможность другим клиентам сделать запрос. Этот ответ не возвращается, когда клиент принудительно остановил передачу по команде пользователя или соединение прервалось по каким-то иным причинам, так как ответ уже послать невозможно. Появился в HTTP/1.1.
409 Conflict — запрос не может быть выполнен из-за конфликтного обращения к ресурсу. Такое возможно, например, когда два клиента пытаются изменить ресурс с помощью метода PUT. Появился в HTTP/1.1.
410 Gone — такой ответ сервер посылает, если ресурс раньше был по указанному URL, но был удалён и теперь недоступен. Серверу в этом случае неизвестно и местоположение альтернативного документа (например копии). Появился в HTTP/1.1.
411 Length Required — для указанного ресурса клиент должен указать Content-Length в заголовке запроса. Без указания этого поля не стоит делать повторную попытку запроса к серверу по данному URI. Такой ответ естественен для запросов типа POST и PUT. Например, если по указанному URI производится загрузка файлов, а на сервере стоит ограничение на их объём. Тогда разумней будет проверить в самом начале заголовок Content-Length и сразу отказать в загрузке, чем провоцировать бессмысленную нагрузку, разрывая соединение, когда клиент действительно пришлёт слишком объёмное сообщение. Появился в HTTP/1.1.
412 Precondition Failed — возвращается, если ни одно из условных полей заголовка (If-Match и др., см. RFC 7232) запроса не было выполнено. Появился в HTTP/1.1.
413 Payload Too Large — возвращается в случае, если сервер отказывается обработать запрос по причине слишком большого размера тела запроса. Сервер может закрыть соединение, чтобы прекратить дальнейшую передачу запроса. Если проблема временная, то рекомендуется в ответ сервера включить заголовок Retry-After с указанием времени, по истечении которого можно повторить аналогичный запрос. Появился в HTTP/1.1. Ранее назывался «Request Entity Too Large».
414 URI Too Long — сервер не может обработать запрос из-за слишком длинного указанного URI. Такую ошибку можно спровоцировать, например, когда клиент пытается передать длинные параметры через метод GET, а не POST. Появился в HTTP/1.1. Ранее назывался «Request-URI Too Long».
415 Unsupported Media Type — по каким-то причинам сервер отказывается работать с указанным типом данных при данном методе. Появился в HTTP/1.1.
416 Range Not Satisfiable — в поле Range заголовка запроса был указан диапазон за пределами ресурса и отсутствует поле If-Range. Если клиент передал байтовый диапазон, то сервер может вернуть реальный размер в поле Content-Range заголовка. Данный ответ не следует использовать при передаче типа multipart/byteranges. Введено в RFC 2616 (обновление HTTP/1.1). Ранее назывался «Requested Range Not Satisfiable».
417 Expectation Failed — по каким-то причинам сервер не может удовлетворить значению поля Expect заголовка запроса. Введено в RFC 2616 (обновление HTTP/1.1).
418 I’m a teapot — Этот код был введен в 1998 году как одна из традиционных первоапрельских шуток IETF в RFC 2324, Hyper Text Coffee Pot Control Protocol. Не ожидается, что данный код будет поддерживаться реальными серверами.
419 Authentication Timeout (not in RFC 2616) — Этого кода нет в RFC 2616, используется в качестве альтернативы коду 401, которые прошли проверку подлинности, но лишены доступа к определенным ресурсам сервера. Обычно код отдается, если CSRF-токен устарел или оказался некорректным.
421 Misdirected Request — запрос был перенаправлен на сервер, не способный дать ответ.
422 Unprocessable Entity — сервер успешно принял запрос, может работать с указанным видом данных (например, в теле запроса находится XML-документ, имеющий верный синтаксис), однако имеется какая-то логическая ошибка, из-за которой невозможно произвести операцию над ресурсом. Введено в WebDAV.
423 Locked — целевой ресурс из запроса заблокирован от применения к нему указанного метода. Введено в WebDAV.
424 Failed Dependency — реализация текущего запроса может зависеть от успешности выполнения другой операции. Если она не выполнена и из-за этого нельзя выполнить текущий запрос, то сервер вернёт этот код. Введено в WebDAV.
425 Too Early — сервер не готов принять риски обработки "ранней информации". Введено в RFC 8470 для защиты от атак повторения при использовании 0-RTT в TLS 1.3.
426 Upgrade Required — сервер указывает клиенту на необходимость обновить протокол. Заголовок ответа должен содержать правильно сформированные поля Upgrade и Connection. Введено в RFC 2817 для возможности перехода к TLS посредством HTTP.
428 Precondition Required — сервер указывает клиенту на необходимость использования в запросе заголовков условий, наподобие If-Match. Введено в черновике стандарта RFC 6585.
429 Too Many Requests — клиент попытался отправить слишком много запросов за короткое время, что может указывать, например, на попытку DDoS-атаки. Может сопровождаться заголовком Retry-After, указывающим, через какое время можно повторить запрос. Введено в черновике стандарта RFC 6585.
431 Request Header Fields Too Large — Превышена допустимая длина заголовков. Сервер не обязан отвечать этим кодом, вместо этого он может просто сбросить соединение. Введено в черновике стандарта RFC 6585.
434 Requested host unavailable — Запрашиваемый адрес недоступен.
449 Retry With — возвращается сервером, если для обработки запроса от клиента поступило недостаточно информации. При этом в заголовок ответа помещается поле Ms-Echo-Request. Введено корпорацией Microsoft для WebDAV. В настоящий момент используется как минимум программой Microsoft Money.
451 Unavailable For Legal Reasons — доступ к ресурсу закрыт по юридическим причинам, например, по требованию органов государственной власти или по требованию правообладателя в случае нарушения авторских прав. Введено в черновике IETF за авторством Google, при этом код ошибки является отсылкой к роману Рэя Брэдбери «451 градус по Фаренгейту». Был добавлен в стандарт 21 декабря 2015 года.
499 Client Closed Request — нестандартный код, предложенный и используемый nginx для случаев, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

5xx: Ошибка сервера

Коды 5xx выделены под случаи необработанных исключений при выполнении операций на стороне сервера. Для всех ситуаций, кроме использования метода HEAD, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.

500 Internal Server Error — любая внутренняя ошибка сервера, которая не входит в рамки остальных ошибок класса. Появился в HTTP/1.0.
501 Not Implemented — сервер не поддерживает возможностей, необходимых для обработки запроса. Типичный ответ для случаев, когда сервер не понимает указанный в запросе метод. Если же метод серверу известен, но он не применим к данному ресурсу, то нужно вернуть ответ 405. Появился в HTTP/1.0.
502 Bad Gateway — сервер, выступая в роли шлюза или прокси-сервера, получил недействительное ответное сообщение от вышестоящего сервера. Появился в HTTP/1.0.
503 Service Unavailable — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). В поле Retry-After заголовка сервер может указать время, через которое клиенту рекомендуется повторить запрос. Хотя во время перегрузки очевидным кажется сразу разрывать соединение, эффективней может оказаться установка большого значения поля Retry-After для уменьшения частоты избыточных запросов. Появился в HTTP/1.0.
504 Gateway Timeout — сервер в роли шлюза или прокси-сервера не дождался ответа от вышестоящего сервера для завершения текущего запроса. Появился в HTTP/1.1.
505 HTTP Version Not Supported — сервер не поддерживает или отказывается поддерживать указанную в запросе версию протокола HTTP. Появился в HTTP/1.1.
506 Variant Also Negotiates — в результате ошибочной конфигурации выбранный вариант указывает сам на себя, из-за чего процесс связывания прерывается. Экспериментальное. Введено в RFC 2295 для дополнения протокола HTTP технологией Transparent Content Negotiation.
507 Insufficient Storage — не хватает места для выполнения текущего запроса. Проблема может быть временной. Введено в WebDAV.
508 Loop Detected — операция отменена, т.к. сервер обнаружил бесконечный цикл при обработке запроса без ограничения глубины. Введено в WebDAV.
509 Bandwidth Limit Exceeded — используется при превышении веб-площадкой отведённого ей ограничения на потребление трафика. В данном случае владельцу площадки следует обратиться к своему хостинг-провайдеру. В настоящий момент данный код не описан ни в одном RFC и используется только модулем «bw/limited», входящим в панель управления хостингом cPanel, где и был введён.
510 Not Extended — на сервере отсутствует расширение, которое желает использовать клиент. Сервер может дополнительно передать информацию о доступных ему расширениях. Введено в RFC 2774 для дополнения протокола HTTP поддержкой расширений.
511 Network Authentication Required — этот ответ посылается не сервером, которому был предназначен запрос, а сервером-посредником — например, сервером провайдера — в случае, если клиент должен сначала авторизоваться в сети, например, ввести пароль для платной точки доступа к Интернету. Предполагается, что в теле ответа будет возвращена Web-форма авторизации или перенаправление на неё. Введено в черновике стандарта RFC 6585.
520 Unknown Error, возникает когда сервер CDN не смог обработать ошибку веб-сервера; нестандартный код CloudFlare.
521 Web Server Is Down, возникает когда подключения CDN отклоняются веб-сервером; нестандартный код CloudFlare.
522 Connection Timed Out, возникает когда CDN не удалось подключиться к веб-серверу; нестандартный код CloudFlare.
523 Origin Is Unreachable, возникает когда веб-сервер недостижим; нестандартный код CloudFlare.
524 A Timeout Occurred, возникает при истечении тайм-аута подключения между сервером CDN и веб-сервером; нестандартный код CloudFlare.
525 SSL Handshake Failed, возникает при ошибке рукопожатия SSL между сервером CDN и веб-сервером; нестандартный код CloudFlare.
526 Invalid SSL Certificate, возникает когда не удаётся подтвердить сертификат шифрования веб-сервера; нестандартный код CloudFlare.

Поля заголовка

General (Общие заголовки): эти поля заголовка имеют общее применение как для сообщений запроса, так и для сообщений ответа.
Request (Заголовки запроса): эти поля заголовка применимы только для сообщений запроса.
Response (Заголовки ответа): эти поля заголовка применимы только для ответных сообщений.
Entity (Заголовки сущности): эти поля заголовка определяют метаинформацию о теле объекта

Общие заголовки

Cache-control

Поле общего заголовка Cache-Control используется для указания директив, которые ДОЛЖНЫ выполняться всей системой кэширования.

HTTP-клиенты или серверы могут использовать общий заголовок Cache-control для указания параметров кеша или для запроса определённых видов документов из кеша. Директивы кэширования указываются в списке, разделённом запятыми. Например:

cache-control: max-age=0, no-cache

Существуют следующие важные директивы запроса кеша, которые клиент может использовать в своём HTTP-запросе:

Директива контроля хеша (для запросов)	Описание
no-cache	Кэш не должен использовать ответ для удовлетворения последующего запроса без успешной повторной проверки на исходном сервере.
no-store	В кеше не должно храниться ничего о запросе клиента или ответе сервера.
max-age=секунды	Указывает, что клиент готов принять ответ, возраст которого не превышает указанного времени в секундах.
max-stale[=секунды]	Указывает, что клиент готов принять ответ, срок действия которого истёк. Если указаны секунды, срок его действия не должен истекать более чем на это время.
min-fresh=секунды	Указывает, что клиент готов принять ответ, время действия которого не меньше его текущего возраста плюс указанное время в секундах.
no-transform	Не конвертировать тело объекта.
only-if-cached	Не извлекать новые данные. Кэш может отправить документ, только если он находится в кеше, и не должен связываться с исходным сервером, чтобы узнать, существует ли более новая копия.

Существуют следующие важные директивы ответа кеша, которые сервер может использовать в своём HTTP-ответе:

Директива контроля хеша (для ответов)	Описание
public	Указывает, что ответ может кэшироваться любым кешем.
private	Указывает, что ответное сообщение полностью или частично предназначено для одного пользователя и не должно кэшироваться в общем кэше.
no-cache	Кэш не должен использовать ответ для удовлетворения последующего запроса без успешной повторной проверки на исходном сервере.
no-store	В кеше не должно храниться ничего о запросе клиента или ответе сервера.
no-transform	Не конвертировать тело объекта.
must-revalidate	Кэш должен проверять статус устаревших документов перед его использованием, и просроченный документ не должен использоваться.
proxy-revalidate	Директива proxy-revalidate имеет то же значение, что и директива must-revalidate, за исключением того, что она не применяется к не разделяемым кешам пользовательских агентов.
max-age=секунды	Указывает, что клиент готов принять ответ, возраст которого не превышает указанное время в секундах.
s-maxage=секунды	Максимальный возраст, указанный в этой директиве, переопределяет максимальный возраст, указанный либо в директиве max-age, либо в заголовке Expires. Директива s-maxage всегда игнорируется частным кешем.

Connection

Общее поле Connection позволяет отправителю указать параметры, которые требуются для этого конкретного соединения и не должны передаваться прокси-серверами по дальнейшим соединениям.

HTTP/1.1 определяет опцию «closed» соединения для отправителя, чтобы сообщить, что соединение будет закрыто после завершения ответа. Например:

Connection: Closed

По умолчанию HTTP 1.1 использует постоянные соединения, при которых соединение не закрывается автоматически после транзакции. HTTP 1.0, с другой стороны, по умолчанию не имеет постоянных соединений. Если клиент 1.0 желает использовать постоянные соединения, он использует параметр keep-alive следующим образом:

Connection: keep-alive

Date

Все метки даты и времени HTTP ДОЛЖНЫ быть представлены в среднем времени по Гринвичу (GMT) без исключения. Приложениям HTTP разрешено использовать любое из следующих трёх представлений меток даты/времени:

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

Здесь первый формат является наиболее предпочтительным.

Pragma

Поле общего заголовка Pragma используется для включения директив, зависящих от реализации, которые могут применяться к любому получателю в цепочке запроса/ответа. Например:

Pragma: no-cache

Единственная директива, определённая в HTTP/1.0, — это директива no-cache, которая поддерживается в HTTP 1.1 для обратной совместимости. Никаких новых директив Pragma в будущем определяться не будет.

Trailer

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

Trailer: название поля

Поля заголовка сообщения, перечисленные в поле заголовка трейлера, не должны включать следующие поля заголовка:

Transfer-Encoding
Content-Length
Trailer

Transfer-Encoding

Поле общего заголовка Transfer-Encoding указывает, какой тип преобразования был применён к телу сообщения, чтобы безопасно передать его между отправителем и получателем. Это не то же самое, что и кодирование содержимого, потому что кодирование передачи является свойством сообщения, а не тела объекта. Ниже приведён синтаксис поля заголовка Transfer-Encoding:

Transfer-Encoding: chunked

Все значения кодирования передачи нечувствительны к регистру.

Upgrade

Общий заголовок Upgrade позволяет клиенту указать, какие дополнительные протоколы связи он поддерживает и хотел бы использовать, если сервер сочтёт целесообразным переключить протоколы. Например:

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Поле заголовка Upgrade предназначено для обеспечения простого механизма перехода с HTTP/1.1 на какой-либо другой несовместимый протокол.

Via

Общий заголовок Via должен использоваться шлюзами и прокси для указания промежуточных протоколов и получателей. Например, сообщение запроса может быть отправлено от пользовательского агента HTTP/1.0 на внутренний прокси-сервер с кодовым именем «fred», который использует HTTP/1.1 для пересылки запроса на общедоступный прокси-сервер на nowhere.com, который завершает запрос пересылка на исходный сервер на www.ics.uci.edu. Запрос, полученный www.ics.uci.edu, будет иметь следующее поле заголовка Via:

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Warning

Общий заголовок Warning используется для передачи дополнительной информации о состоянии или преобразовании сообщения, которая может не отражаться в сообщении. Ответ может содержать более одного заголовка «Warning».

Warning: [код предупреждения] [агент предупреждения] [текст предупреждения] [дата предупреждения]

Заголовки клиентских запросов

Accept

Поле заголовка запроса Accept может использоваться для указания определённых типов медиа, которые приемлемы для ответа. Ниже приводится общий синтаксис:

Accept: тип/подтип; [q=значение]

Несколько типов медиа могут быть перечислены через запятую, а необязательная переменная q представляет приемлемый уровень качества для принимаемых типов по шкале от 0 до 1. Цвет показывает связанные значения:

Accept: тип/подтип; [q=значение], тип/подтип; [q=значение], тип/подтип

Пример:

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

Это будет интерпретироваться как: text/html и text/x-c являются предпочтительными типами мультимедиа, но если они не существуют, отправьте объект text/x-dvi, а если он не существует, отправьте объект text/plain.

Accept-Charset

Поле заголовка запроса Accept-Charset может использоваться, чтобы указать, какие наборы символов приемлемы для ответа. Ниже приводится общий синтаксис:

Accept-Charset: набор_символов [q=значение]

Несколько наборов символов могут быть перечислены через запятую, а необязательная q представляет приемлемый уровень качества для второстепенных наборов символов по шкале от 0 до 1. Пример:

Accept-Charset: iso-8859-5, unicode-1-1; q=0.8

Специальное значение «*», если оно присутствует в поле Accept-Charset, соответствует каждому набору символов, а если заголовок Accept-Charset отсутствует, по умолчанию допустим любой набор символов.

Accept-Encoding

Поле заголовка запроса Accept-Encoding аналогично Accept, но ограничивает допустимые в ответе кодировки содержимого. Общий синтаксис:

Accept-Encoding: типы кодирования

Примеры:

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Accept-Language

Поле заголовка запроса Accept-Language аналогично Accept, но ограничивает набор естественных языков, которые предпочтительны в качестве ответа на запрос. Синтаксис:

Accept-Language: язык;[q=значение]

Несколько языков можно перечислить через запятую, а необязательное значение q представляет приемлемый уровень качества по шкале от 0 до 1 для второстепенных языков. Ниже приводится пример:

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Authorization

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

Authorization: учётные данные

Спецификация HTTP/1.0 определяет схему авторизации BASIC, где параметром авторизации является строка имя пользователя:пароль в кодировке base64. Пример:

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

Значение декодируется в guest:guest123, где guest — идентификатор пользователя, а guest123 — пароль.

Cookie

Значение поля заголовка запроса cookie содержит пару имя/значение информации, хранящейся для этого URL. Ниже приводится общий синтаксис:

Cookie: имя=значение

Несколько файлов cookie можно указать через точку с запятой следующим образом:

Cookie: name1=value1;name2=value2;name3=value3

Expect

Поле заголовка запроса Expect используется для указания того, что конкретное поведение сервера требуется клиенту. Ниже приводится общий синтаксис:

Expect: 100-continue | expectation-extension

Если сервер получает запрос, содержащий поле Expect, которое включает расширение ожидания, которое он не поддерживает, он должен ответить статусом 417 (Expectation Failed), (ожидание не выполнено).

From

Поле заголовка запроса From содержит адрес электронной почты в Интернете для человека-пользователя, который управляет запрашивающим агентом пользователя. Вот простой пример:

From: webmaster@w3.org

Это поле заголовка может использоваться для целей регистрации и как средство для определения источника недопустимых или нежелательных запросов.

Host

Поле заголовка запроса Host используется для указания хоста в Интернете и номера порта запрашиваемого ресурса. Общий синтаксис:

Хост: хост[:порт];

Хост без какой-либо информации о конечном порте подразумевает порт по умолчанию, который равен 80. Например, запрос на сервер для http://www.w3.org/pub/WWW/ будет следующим:

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

Поле заголовка запроса If-Match используется с методом, чтобы сделать его условным. Этот заголовок запрашивает у сервера выполнение запрошенного метода, только если данное значение в этом теге совпадает с заданными тегами объекта, указанным как объект-тег. Общий синтаксис:

If-Match: объект-тег

Звёздочка (*) соответствует любому объекту, и транзакция продолжается, только если объект существует. Ниже приведены возможные примеры:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

Если ни один из тегов объекта не совпадает, или если дан "*" и текущий объект не существует, сервер не должен выполнять запрошенный метод и должен вернуть ответ 412 (Precondition Failed).

Подробности смотрите в описании тэга ETag, которым может быть прислано значение объект-тега.

If-Modified-Since

Поле заголовка запроса If-Modified-Since используется с методом, чтобы сделать его условным. Если запрошенный URL-адрес не был изменён с момента времени, указанного в этом поле, объект не будет возвращён с сервера; вместо этого будет возвращён ответ 304 (без изменений) без тела сообщения. Общий синтаксис:

If-Modified-Since: HTTP-дата

Пример поля:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

If-None-Match

Поле заголовка запроса If-None-Match используется с методом, чтобы сделать его условным. Этот заголовок запрашивает у сервера выполнение запрошенного метода, только если ни одно из заданных значений не совпадает с представленными объект-тегом. Ниже приводится общий синтаксис:

If-None-Match: объект-тег

Звёздочка (*) соответствует любому объекту, и транзакция продолжается, только если объект не существует. Ниже приведены возможные примеры:

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

Подробности смотрите в описании тэга ETag, которым может быть прислано значение объект-тега.

Заголовок HTTP-запроса If-None-Match делает запрос условным. Для методов GET и HEAD сервер отправит обратно запрошенный ресурс со статусом 200, только если у него нет ETag, соответствующего данным. Для других методов запрос будет обработан только в том случае, если ETag существующего в конечном итоге ресурса не соответствует ни одному из перечисленных значений.

If-Range

Поле заголовка запроса If-Range может использоваться с условным GET для запроса только той части сущности, которая отсутствует, если она не была изменена, и всей сущности, если она была изменена. Ниже приводится общий синтаксис:

If-Range: объект-тег | HTTP-дата

Для идентификации уже полученной частичной сущности можно использовать тег объекта или дату. Например:

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

Здесь, если документ не был изменён с указанной даты, сервер возвращает диапазон байтов, заданный заголовком Range, в противном случае он возвращает весь новый документ.

If-Unmodified-Since

Поле заголовка запроса If-Unmodified-Since используется с методом, чтобы сделать его условным. Синтаксис:

If-Unmodified-Since: HTTP-дата

Если запрошенный ресурс не был изменён с момента времени, указанного в этом поле, сервер должен выполнить запрошенную операцию, как если бы заголовок If-Unmodified-Since отсутствовал. Например:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Обычно если запрос приводит к чему-либо, кроме статуса 2xx или 412, заголовок If-Unmodified-Since следует игнорировать.

Max-Forwards

Поле заголовка запроса Max-Forwards предоставляет механизм с методами TRACE и OPTIONS для ограничения количества прокси или шлюзов, которые могут пересылать запрос на следующий входящий сервер. Ниже приводится общий синтаксис:

Max-Forwards: ЧИСЛО

Значение Max-Forwards — это десятичное целое число, указывающее оставшееся количество раз, когда это сообщение запроса может быть переадресовано. Это полезно для отладки с помощью метода TRACE, избегая бесконечных циклов. Например:

Max-Forwards: 5

Поле заголовка Max-Forwards можно игнорировать для всех других методов, определённых в спецификации HTTP.

Proxy-Authorization

Поле заголовка запроса Proxy-Authorization позволяет клиенту идентифицировать себя (или своего пользователя) для прокси, который требует аутентификации. Ниже приводится общий синтаксис:

Proxy-Authorization: учётные данные

Значение поля Proxy-Authorization состоит из учётных данных, содержащих информацию аутентификации пользовательского агента для прокси и/или области запрашиваемого ресурса.

Range

Поле заголовка запроса Range указывает частичный диапазон(ы) содержимого, запрошенного из документа. Синтаксис:

Range: bytes=первый байт-[последний байт]

Значение первый байт означает байтовое смещение первого байта в диапазоне. Значение последний байт означает байтовое смещение последнего байта в диапазоне; то есть указанные позиции байтов являются включительными.

- Первые 500 байт
Range: bytes=0-499

- Вторые 500 байт
Range: bytes=500-999

- Последние 500 байт
Range: bytes=-500

- Только первый и последний байты
Range: bytes=0-0,-1

Можно указать несколько диапазонов, разделённых запятыми. Если первая цифра в диапазоне(ах) байтов, разделённых запятыми, отсутствует, предполагается, что диапазон отсчитывается от конца документа. Если вторая цифра отсутствует, диапазон равен байтам до конца документа.

Referer

Поле заголовка запроса Referer позволяет клиенту указать адрес (URI) ресурса, из которого был запрошен URL. Ниже приводится общий синтаксис:

Referer: абсолютный или относительный URI

Вот простой пример:

Referer: httpы://hackware.ru

Если значение поля является относительным URI, его следует интерпретировать относительно запрошенного URI.

Поле заголовка запроса TE указывает, какое расширение кодирования передачи он готов принять в ответе, и готов ли он принимать поля trailer звеньев в кодировании передачи по частям (chunked).

Ниже приводится общий синтаксис:

TE: кодировки передачи

Наличие ключевого слова «trailers» указывает на то, что клиент готов принять поля trailers в фрагментированном кодировании передачи, и это указывается одним из способов:

TE: deflate
TE:
TE: trailers, deflate;q=0.5

Если значение поля TE пусто или если поле TE отсутствует, единственное кодирование передачи разбивается на блоки. Сообщение без кодирования передачи всегда приемлемо.

User-Agent

Поле заголовка запроса User-Agent содержит информацию о пользовательском агенте, создавшем запрос. Ниже приводится общий синтаксис:

User-Agent: продукт | комментарий

Пример:

User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/86.0.4240.111 Safari/537.36

Заголовки ответа сервера

Accept-Ranges

Поле заголовка ответа Accept-Ranges позволяет серверу указать, что он принимает запросы диапазона для ресурса. Синтаксис:

Accept-Ranges: единица-диапазона | none

Например, сервер, который принимает запросы байтового диапазона, может отправлять

Accept-Ranges: bytes

Серверы, которые не принимают какие-либо запросы диапазона для ресурса, могут отправлять:

Accept-Ranges: none

Это посоветует клиенту не пытаться выполнить запрос диапазона.

Age

Поле заголовка ответа Age передаёт примерное количество времени, прошедшего с момента создания ответа (или его повторной проверки) на исходном сервере. Синтаксис:

Age: дельта-секунды

Значения Age являются неотрицательными десятичными целыми числами, представляющими время в секундах. Пример:

Age: 1030

Сервер HTTP/1.1, который включает кеш, должен включать поле заголовка Age в каждый ответ, сгенерированный из его собственного кеша.

ETag

Поле заголовка ответа ETag содержит текущее значение тега объекта для запрошенного варианта. Синтаксис:

ETag: объект-тег

Примеры:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

ETag или entity tag — один из, регламентируемый спецификацией RFC 7232, служебных заголовков протокола HTTP/1.1, который может быть установлен веб-сервером в фазе формирования ответа, на полученный от клиента запрос. Содержимое заголовка ETag является идентификатором, значение которого прямо зависит от состояния загружаемого клиентом ресурса. В дальнейшем, этот идентификатор, используется с целью актуализации состояния загруженного ресурса его оригиналу, расположенному на Веб-сервере. Что достигается путём отправки серверу HTTP/1.1 запроса с указанием ETag идентификатора как значении заголовка — If-None-Match. Сервер, обнаружив такой заголовок, на основании сравнения его значения с текущим состоянием ресурса сообщает клиенту о том, что копия, хранящаяся в кэше клиента, актуальна т.е. необходимости в повторной загрузке нет, или, в противном случае, необходима загрузка актуальной версии.

ETag — это закрытый идентификатор, присвоенный веб-сервером на определённую версию ресурса, найденного на URL. Если содержание ресурса для этого адреса меняется на новое, назначается и новый ETag. Использование в таком ключе ETags аналогично использованию отпечатков пальцев, можно быстро сравнить и определить, являются ли две версии ресурса одинаковыми или нет. Сравнение ETag имеет смысл только c Etag с одного и того же URL, идентификаторы, полученные из разных URL-адресов, могут быть равны, а могут быть нет, вне зависимости от ресурсов, так что их сравнение не имеет какого-либо смысла.

Использование ETags в заголовке HTTP не является обязательным (как и некоторые другие поля заголовка HTTP 1.1). Метод, с помощью которого ETags генерируются, никогда не был указан в спецификации HTTP.

При обычном использовании, когда извлекается URL, веб-сервер вернет ресурс вместе с соответствующим значением ETag, который находится в поле HTTP ETag:

ETag: "686897696a7c876b7e"

Клиент может затем кэшировать ресурс вместе с его ETag. Позже, если клиент хочет получить страницу с того же адреса, он пошлет её ранее сохранённую копию ETag вместе с запросом в поле If-None-Match.

If-None-Match: "686897696a7c876b7e"

На этот последующий запрос сервер может теперь сравнить ETag клиента с ETag для текущей версии ресурса. Если значения ETag совпадают, это означает, что ресурс не изменился, сервер может отправить обратно очень короткий ответ с HTTP статусом 304 Not Modified. Статус 304 сообщает клиенту, что его кэш версия по-прежнему актуальна и что он должен использовать её.

Однако, если ETag-значения не совпадают, то есть ресурс, скорее всего, изменился, то полный ответ, в том числе содержание ресурса, возвращаются, как будто ETag не использовался. В этом случае клиент может принять решение о замене в кэше версии ресурса на вновь возвращённую и новый ETag.

ETag можно использовать в веб-страницах для системы мониторинга за изменениями и уведомлениями. Эффективному мониторингу веб-страницы мешает тот факт, что большинство веб-сайтов не устанавливают Etag заголовки веб-страниц. Когда веб-монитор не имеет никаких подсказок, был ли веб-контент изменён, весь контент должен быть восстановлен и проанализирован, используя вычислительные ресурсы как опубликовавшего контент, так и того, кто хочет его просмотреть.

ETags может быть использована для отслеживания уникальных пользователей, так как HTTP cookie могут быть удалены стремящимися к полной конфиденциальности пользователями. В июле 2011 года Ashkan Солтани и команда исследователей из Калифорнийского университета в Беркли сообщили, что ряд веб-сайтов, в том числе Hulu.com, использовали ETag для отслеживания таких целей. Hulu и KISSmetrics перестали это делать по состоянию на 29 июля 2011,так как KISSmetrics и более 20 её клиентов столкнулись с групповым иском по поводу использования «неудаляемых» следящих cookie частично связанных с использованием ETag.

Location

Поле заголовка ответа Location используется для перенаправления получателя в местоположение, отличное от URI запроса. Синтаксис:

Location: абсолютный URI

Пример:

Location: https://hackware.ru

Поле заголовка Content-Location отличается от Location тем, что Content-Location идентифицирует исходное местоположение объекта, заключённого в запрос.

Proxy-Authenticate

Поле заголовка ответа Proxy-Authenticate должно быть включено как часть ответа 407 (Proxy Authentication Required). Синтаксис:

Proxy-Authenticate: вызов

Retry-After

Поле заголовка ответа Retry-After может использоваться с ответом 503 (служба недоступна), чтобы указать, как долго служба, как ожидается, будет недоступна для запрашивающего клиента. Синтаксис:

Retry-After: HTTP-дата | дельта-секунды

Примеры:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

В последнем примере задержка составляет 2 минуты.

Server

Поле заголовка ответа сервера содержит информацию о программном обеспечении, используемом исходным сервером для обработки запроса. Синтаксис:

Server: продукт | комментарий

Пример:

Server: Apache/2.4.46 (Unix) PHP/7.4.12

Если ответ пересылается через прокси, прокси-приложение не должно изменять заголовок ответа сервера.

Set-Cookie

Поле заголовка ответа Set-Cookie содержит пару имя/значение информации, которую необходимо сохранить для этого URL. Синтаксис:

Set-Cookie: ИМЯ=ЗНАЧЕНИЕ; ПАРАМЕТРЫ

Заголовок ответа Set-Cookie состоит из токена Set-Cookie:, за которым следует список из одного или нескольких файлов cookie, разделённых запятыми. Вот возможные значения, которые вы можете указать в качестве опций:

Опции	Описание
Comment=комментарий	Этот параметр можно использовать для указания любого комментария, связанного с файлом cookie.
Domain=домен	Атрибут Domain указывает домен, для которого действует cookie.
Expires=Дата-время	Дата истечения срока действия cookie. Если это поле пусто, срок действия cookie истечёт, когда посетитель закроет браузер.
Path=путь	Атрибут Path указывает подмножество URL-адресов, к которым применяется этот файл cookie.
Secure	Это указывает пользовательскому агенту возвращать cookie только при безопасном соединении.

Пример заголовка файла cookie, созданного сервером:

Set-Cookie: имя1=значение1,имя2=значение2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

Поле заголовка ответа Vary указывает, что объект имеет несколько источников и, следовательно, может варьироваться в зависимости от указанного списка заголовков запроса. Синтаксис:

Vary: СТРОКА

Вы можете указать несколько значений, разделённых запятыми, а значение звёздочки «*» сигнализирует о том, что неуказанные параметры не ограничиваются заголовками запроса. Пример:

Vary: Accept-Language, Accept-Encoding

Здесь имена полей не чувствительны к регистру.

Предыдущий пример означает, что присланное содержимое различается в зависимости от языка, установленного полем Accept-Language и выбранным методом кодирования содержимого, который указан в поле Accept-Encoding.

Ещё один пример:

Vary: User-Agent

означает, что присланное содержимое зависит от веб-браузера пользователя.

Vary имеет значение, например, для программ кэширования. Эти программы будут создавать кэш одной и той же страницы для каждой версии браузера, если указано значение «Vary: User-Agent».

WWW-Authenticate

Поле заголовка ответа WWW-Authenticate должно быть включено в ответное сообщение 401 (Unauthorized). Значение поля состоит как минимум из одного запроса, который указывает схему (схемы) аутентификации и параметры, применимые к запрошенному URI. Синтаксис:

WWW-Authenticate: ПАРАМЕТРЫ | ВЫЗОВ

Значение поля WWW-Authenticate может содержать более одного вызова (challenge). В заголовке может быть более одного WWW-Authenticate. Здесь может содержаться также список параметров аутентификации, разделённых запятыми. Примеры:

WWW-Authenticate: Basic realm="For registered members only"

WWW-Authenticate: Digest realm="USERS", nonce="5Ud3naayBQA=2753b701c1b09141fab25b13510f05570f280a8f", algorithm=MD5, domain="/", qop="auth"

Заголовки сущности

Allow

В поле Allow заголовка сущности перечислен набор методов, поддерживаемых ресурсом, указанным в запрошенном URI. Синтаксис:

Allow: Метод

Вы можете указать несколько методов через запятую. Пример:

Allow: GET, HEAD, PUT

Это поле не может помешать клиенту попробовать другие методы.

Content-Encoding

Поле заголовка сущности Content-Encoding используется в качестве модификатора типа медиа. Синтаксис:

Content-Encoding: контент-кодирование

Контент-кодирование — это характеристика объекта, указанного в запрошенном URI. Пример:

Content-Encoding: gzip

Если кодирование содержимого объекта в сообщении запроса неприемлемо для исходного сервера, сервер должен ответить кодом состояния 415 (Unsupported Media Type), (неподдерживаемый тип медиа).

Content-Language

Поле заголовка объекта Content-Language описывает естественный язык (языки) целевой аудитории для вложенного объекта. Ниже приводится общий синтаксис:

Content-Language: язык

Для контента, предназначенного для разных аудиторий, может быть указано несколько языков. Наример:

Content-Language: mi, en

Основная цель Content-Language — позволить пользователю идентифицировать и различать объекты в соответствии с его собственным предпочтительным языком.

Content-Length

Поле заголовка объекта Content-Length указывает размер тела объекта, отправленных получателю, или, в случае метода HEAD, размер тела объекта, которое было бы отправлено, если бы запрос был GET. Синтаксис:

Content-Length: ЦИФРЫ

Пример:

Content-Length: 3495

Любое значение Content-Length больше или равное нулю является допустимым значением.

Content-Location

Поле заголовка объекта Content-Location может использоваться для предоставления местоположения ресурса для объекта, заключённого в сообщение, когда этот объект доступен из местоположения, отдельного от URI запрошенного ресурса. Синтаксис:

Content-Location: абсолютный URI | относительный URI

Пример:

Content-Location: https://hackware.ru

Значение Content-Location также определяет базовый URI для объекта.

Content-MD5

Поле заголовка объекта Content-MD5 может использоваться для предоставления дайджеста (контрольной суммы) объекта MD5 для проверки целостности сообщения при его получении. Синтаксис:

Content-MD5: md5-дайджест с использованием 128-битного дайджеста MD5 base64 согласно RFC 1864

Наример:

Content-MD5: 8c2d46911f3f5a326455f0ed7a8ed3b3

Дайджест MD5 вычисляется на основе содержимого тела объекта, включая любое применённое кодирование содержимого, но не включая кодирование передачи, применённое к телу сообщения.

Content-Range

Поле заголовка объекта Content-Range отправляется с частичным телом объекта, чтобы указать, какой фрагмент прислан. Синтаксис:

Content-Range: первый байт-последний байт/общая длина

Примеры значений, предполагая, что объект содержит всего 1234 байта:

- Первые 500 байт:
Content-Range: bytes 0-499/1234

- Вторые 500 байт:
Content-Range: bytes 500-999/1234

- Все, кроме первых 500 байтов:
Content-Range: bytes 500-1233/1234

- Последние 500 байтов:
Content-Range: bytes 734-1233/1234

Когда сообщение HTTP включает в себя неполное содержимое, это содержимое передаётся с заголовком Content-Range и заголовком Content-Length, показывающим количество фактически переданных байтов. Например,

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Content-Type

Поле заголовка объекта Content-Type указывает тип носителя тела объекта, отправленного получателю, или, в случае метода HEAD, тип носителя, который был бы отправлен, если бы запрос был GET. Синтаксис:

Content-Type: тип-медиа

Пример:

Content-Type: text/html; charset=ISO-8859-4

Expires

В поле заголовка объекта Expires указывается дата/время, после которых ответ считается устаревшим. Синтаксис:

Expires: HTTP-дата

Пример:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

Поле заголовка объекта Last-Modified указывает дату и время, когда исходный сервер считает, что файл был последний раз изменён. Синтаксис:

Last-Modified: HTTP-дата

Пример:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

Кеширование

HTTP обычно используется для распределенных информационных систем, где производительность может быть улучшена за счёт использования кэшей ответов. Протокол HTTP/1.1 включает ряд элементов, предназначенных для работы кеширования.

Целью кэширования в HTTP/1.1 является сокращение количества отправленных запросов и сокращение количество отправленных полных ответов.

Основные механизмы кеширования в HTTP/1.1 — это неявные директивы для кешей, в которых сервер указывает время истечения срока действия и валидаторы. Для этого мы используем заголовок Cache-Control.

Заголовок Cache-Control позволяет клиенту или серверу передавать различные директивы в запросах или ответах. Эти директивы обычно переопределяют алгоритмы кэширования установленные по умолчанию. Директивы кэширования указываются в списке, разделённом запятыми. Например:

Cache-control: no-cache

или:

cache-control: max-age=0, no-cache

Существуют следующие важные директивы запроса кеша, которые клиент может использовать в своём HTTP-запросе:

Директива контроля кэша (для запросов)	Описание
no-cache	Кэш не должен использовать ответ для удовлетворения последующего запроса без успешной повторной проверки на исходном сервере.
no-store	В кеше не должно храниться ничего о запросе клиента или ответе сервера.
max-age=секунды	Указывает, что клиент готов принять ответ, возраст которого не превышает указанное время в секундах.
max-stale[=секунды]	Указывает, что клиент готов принять ответ, срок действия которого истёк. Если указаны секунды, срок его действия не должен истекать более чем на это время.
min-fresh=секунды	Указывает, что клиент готов принять ответ, время действия которого не меньше его текущего возраста плюс указанное время в секундах.
no-transform	Не конвертировать тело объекта.
only-if-cached	Не извлекать новые данные. Кэш может отправить документ, только если он находится в кеше, и не должен связываться с исходным сервером, чтобы узнать, существует ли более новая копия.

Существуют следующие важные директивы ответа кеша, которые сервер может использовать в своём HTTP-ответе:

Директива контроля кэша (для ответов)	Описание
public	Указывает, что ответ может кэшироваться любым кешем.
private	Указывает, что ответное сообщение полностью или частично предназначено для одного пользователя и не должно кэшироваться в общем кэше.
no-cache	Кэш не должен использовать ответ для удовлетворения последующего запроса без успешной повторной проверки на исходном сервере.
no-store	В кеше не должно храниться ничего о запросе клиента или ответе сервера.
no-transform	Не конвертировать тело объекта.
must-revalidate	Кэш должен проверять статус устаревших документов перед его использованием, и просроченный документ не должен использоваться.
proxy-revalidate	Директива proxy-revalidate имеет то же значение, что и директива must-revalidate, за исключением того, что она не применяется к не разделяемым кешам пользовательских агентов.
max-age=секунды	Указывает, что клиент готов принять ответ, возраст которого не превышает указанное время в секундах.
s-maxage=секунды	Максимальный возраст, указанный в этой директиве, переопределяет максимальный возраст, указанный либо в директиве max-age, либо в заголовке Expires. Директива s-maxage всегда игнорируется частным кешем.

Кодировка URL

URL-адреса HTTP, который часто содержит символы вне набора ASCII, могут быть отправлены через Интернет только с использованием набора символов ASCII. Поэтому эти небезопасные символы необходимо заменить на %, за которым следуют две шестнадцатеричные цифры.

В следующей таблице показан символ ASCII и его эквивалентный символ, а также его замена, которую можно использовать в URL-адресе перед передачей на сервер:

ASCII	Символ	Замена
< 32		Кодируется с помощью %xx, где xx — шестнадцатеричное представление символа.
32	пробел	+ или %20
33	!	%21
34	"	%22
35	#	%23
36	$	%24
37	%	%25
38	&	%26
39	'	%27
40	(	%28
41	)	%29
42	*	*
43	+	%2B
44	,	%2C
45	—	—
46	.	.
47	/	%2F
48	0	0
49	1	1
50	2	2
51	3	3
52	4	4
53	5	5
54	6	6
55	7	7
56	8	8
57	9	9
58	:	%3A
59	;	%3B
60	<	%3C
61	=	%3D
62	>	%3E
63	?	%3F
64	@	%40
65	A	A
66	B	B
67	C	C
68	D	D
69	E	E
70	F	F
71	G	G
72	H	H
73	I	I
74	J	J
75	K	K
76	L	L
77	M	M
78	N	N
79	O	O
80	P	P
81	Q	Q
82	R	R
83	S	S
84	T	T
85	U	U
86	V	V
87	W	W
88	X	X
89	Y	Y
90	Z	Z
91	[	%5B
92	\	%5C
93	]	%5D
94	^	%5E
95	_	_
96	`	%60
97	a	a
98	b	b
99	c	c
100	d	d
101	e	e
102	f	f
103	g	g
104	h	h
105	i	i
106	j	j
107	k	k
108	l	l
109	m	m
110	n	n
111	o	o
112	p	p
113	q	q
114	r	r
115	s	s
116	t	t
117	u	u
118	v	v
119	w	w
120	x	x
121	y	y
122	z	z
123	{	%7B
124	\|	%7C
125	}	%7D
126	~	%7E
127		%7F
> 127		Кодируется с помощью %xx, где xx — шестнадцатеричное представление символа.

Сервис: онлайн кодирование и раскодирование.

Безопасность

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

Утечка личной информации

HTTP-клиенты (веб-браузеры) часто имеют доступ к большим объёмам личной информации, такой как имя пользователя, местонахождение, почтовый адрес, пароли, ключи шифрования и т. д. Поэтому вы должны быть очень осторожны, чтобы предотвратить непреднамеренную утечку этой информации через HTTP-протокол в другие источники.

Вся конфиденциальная информация должна храниться на стороне сервера в зашифрованном виде.
Выявление конкретной версии программного обеспечения сервера может сделать серверный компьютер более уязвимым для атак на программное обеспечение, которое, как известно, содержит бреши в безопасности.
Прокси-серверы, которые служат порталом через сетевой брандмауэр, должны принимать особые меры предосторожности в отношении передачи информации в заголовках, которая идентифицирует хосты за брандмауэром.
Информация, отправляемая в поле «From», может вступать в конфликт с интересами конфиденциальности пользователя или политикой безопасности, и, следовательно, её нельзя передавать, если пользователь не сможет отключить, включить или изменить содержимое поля.
Клиенты не должны включать поле заголовка Referer в (небезопасный) HTTP-запрос, если ссылающаяся страница была передана по безопасному протоколу.
Авторам служб, использующих протокол HTTP, не следует использовать формы на основе GET для отправки конфиденциальных данных, потому что это приведёт к кодированию этих данных в URI, то есть зная адрес, который открыл пользователь, можно узнать введённую им информацию.

Атака на основе имён файлов и путей

Доступ к документам, возвращаемыми HTTP-запросами, должен быть ограничен только теми, которые были предназначены администраторами сервера для отправки.

Например, UNIX, Microsoft Windows и другие операционные системы используют .. в качестве компонента пути, чтобы указать уровень каталога выше текущего. В такой системе HTTP-сервер ДОЛЖЕН запретить любую такую конструкцию из этих элементов в запрошенном URI, если в противном случае может быть получен доступ к ресурсу за пределами тех, которые должны быть доступны через HTTP-сервер.

Подмена DNS

Клиенты, использующие HTTP, в значительной степени полагаются на службу доменных имён и, следовательно, обычно подвержены атакам на безопасность, основанным на преднамеренном неправильном сопоставлении IP-адресов и имён DNS. Таким образом, клиенты должны быть осторожны, предполагая постоянную действительность ассоциации IP-адреса и имени DNS.

Если HTTP-клиенты кэшируют результаты поиска имени хоста, чтобы добиться повышения производительности, они должны соблюдать информацию из TTL, сообщаемую DNS. Если клиенты HTTP не соблюдают это правило, они могут быть подделаны при изменении IP-адреса сервера, к которому ранее осуществлялся доступ.

Заголовки местоположения и спуфинг

Если один сервер поддерживает несколько организаций, которые не доверяют друг другу, он ДОЛЖЕН проверять значения заголовков Location и Content-Location в ответах, которые генерируются под контролем указанных организаций, чтобы убедиться, что они не пытаются аннулировать ресурсы, на которые у них нет власти.

Учётные данные для аутентификации

Существующие HTTP-клиенты и пользовательские агенты обычно хранят аутентификационную информацию на неопределённый срок. HTTP/1.1. не предоставляет серверу способа направить клиентам запрос на сброс этих кэшированных учётных данных, что представляет большую угрозу безопасности.

Существует несколько способов решения этой проблемы, поэтому рекомендуется принимать меры, препятствующие доступу посторонних к компьютеру как во включённом состоянии (блокировка экрана по таймауту), так и в выключенном.

Прокси и кеширование

HTTP-прокси представляют собой возможность для атак типа «человек посередине». Прокси-серверы имеют доступ к информации, связанной с безопасностью, личной информации об отдельных пользователях и организациях, а также частной информации, принадлежащей пользователям и поставщикам контента.

Операторы прокси должны защищать системы, на которых работают прокси, так же как они защищают любую систему, которая содержит или транспортирует конфиденциальную информацию.

Кэширующие прокси-серверы предоставляют дополнительные потенциальные уязвимости, поскольку содержимое кеша представляет собой привлекательную цель для злонамеренного использования. Следовательно, содержимое кеша следует защищать как конфиденциальную информацию.

Примеры сообщений

Пример 1

HTTP-запрос для получения страницы hello.htm с веб-сервера, запущенного на hackware.ru

Запрос клиента

GET /hello.htm HTTP/2
Host: hackware.ru
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: .........................................
Upgrade-Insecure-Requests: 1
Cache-Control: max-age=0

Ответ сервера

HTTP/2 200 OK
server: nginx
content-type: text/html
vary: Accept-Encoding
date: Thu, 05 Nov 2020 15:09:09 GMT
x-page-speed: 1.13.35.2-0
cache-control: max-age=0, no-cache
content-encoding: gzip
X-Firefox-Spdy: h2

Пример 2

HTTP-запрос для получения страницы t.html, которая не существует на веб-сервере, запущенном на hackware.ru

Запрос клиента

GET /t.html HTTP/2
Host: hackware.ru
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Firefox/82.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Cookie: ...........................................
Upgrade-Insecure-Requests: 1

Ответ сервера

HTTP/2 404 Not Found
server: nginx
content-type: text/html; charset=iso-8859-1
vary: Accept-Encoding
date: Thu, 05 Nov 2020 15:10:36 GMT
x-page-speed: 1.13.35.2-0
cache-control: max-age=0, no-cache
content-encoding: gzip
X-Firefox-Spdy: h2

Пример 3

HTTP-запрос для получения страницы hello.htm с веб-сервера, работающего на site.com, но запрос идёт с неправильной версией HTTP:

Запрос клиента

GET /hello.htm HTTP1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: site.com
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

Ответ сервера

HTTP/1.1 400 Bad Request
Date: Sun, 18 Oct 2012 10:36:20 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 230
Content-Type: text/html; charset=iso-8859-1
Connection: close
   
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html>
<head>
   <title>400 Bad Request</title>
</head>
<body>
   <h1>Bad Request</h1>
   <p>Your browser sent a request that this server could not understand.<p>
   <p>The request line contained invalid characters following the protocol string.<p>
</body>
</html>

Пример 4

HTTP-запрос для отправки данных формы на CGI-страницу process.cgi на веб-сервере, работающем на сайте site.com. Затем сервер возвращает переданное имя для установки его как файлов cookie:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: site.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

Ответ сервера

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-Length: 88
Set-Cookie: first=Zara,last=Ali;domain=site.com;Expires=Mon, 19-
Nov-2010 04:38:14 GMT;Path=/
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Hello Zara Ali</h1>
</body>
</html>

Источник: в значительной степени основывается на https://www.tutorialspoint.com/http/http_quick_guide.htm

HackWare.ru

Этичный хакинг и тестирование на проникновение, информационная безопасность

HTTP протокол

Оглавление: Компьютерные сети

Что такое HTTP

Основные характеристики

Базовая архитектура

Параметры

Сообщения

Как посмотреть HTTP заголовки

Как в веб-браузере увидеть HTTP заголовки

Как в cURL посмотреть HTTP заголовки

HTTP заголовки в Wireshark (только для протокола HTTP, без HTTPS)

HTTP заголовки в Burp Suite

Запросы

Ответы

Методы

Метод GET

Метод HEAD

Метод POST

Метод PUT

Метод DELETE

Метод CONNECT

Метод OPTIONS

Метод TRACE

Как отправить HTTP запрос методом OPTIONS и другими методами

OPTIONS /путь

OPTIONS *

Как отправить HTTP запрос с произвольным методом

Опция -X в cURL

Коды состояния

1xx: Информационные

2xx: Успех

3xx: Перенаправление

4xx: Ошибка клиента

5xx: Ошибка сервера

Поля заголовка

Общие заголовки

Заголовки клиентских запросов

Заголовки ответа сервера

Заголовки сущности

Кеширование

Кодировка URL

Безопасность

Утечка личной информации

Атака на основе имён файлов и путей

Подмена DNS

Заголовки местоположения и спуфинг

Учётные данные для аутентификации

Прокси и кеширование

Примеры сообщений

Пример 1

Пример 2

Пример 3

Пример 4

Связанные статьи:

Рекомендуется Вам:

Добавить комментарий Отменить ответ