HTTP

HTTP
Название	Hypertext Transfer Protocol
Уровень (по �одели OSI)	Прикладной
Се�ейство	TCP/IP
Создан в	1990
РџРѕСЂС‚/ID	80/TCP
Спецификация	RFC 124, RFC 1945, RFC 2616, RFC 2617, RFC 6266, RFC 7230, RFC 7240, RFC 8446, RFC 9110.
Основные реализации (клиенты)	Веб-браузеры, напри�ер, Internet Explorer, Mozilla Firefox, Opera, Google Chrome, Яндекс.�раузер, Microsoft Edge и др.
Основные реализации (серверы)	Apache, IIS, nginx, Google Web Server и др.
 РњРµРґРёР°С„айлы РЅР° Викискладе

HTTP (англ. HyperText Transfer Protocol вЂ” «протокол передачи гипертекста») вЂ” сетевой протокол прикладного СѓСЂРѕРІРЅСЏ, который изначально предназначался для получения СЃ серверов гипертекстовых РґРѕРєСѓР�ентов РІ форР�ате HTML, Р° СЃ течениеР� РІСЂРµР�ени стал универсальныР� средствоР� взаиР�одействия Р�ежду узлаР�Рё как Р’СЃРµР�РёСЂРЅРѕР№ паутины, так Рё изолированных веб-инфраструктур. Определение РїРѕ РѕСЃРЅРѕРІРЅС‹Р� РґРѕРєСѓР�ентацияР�: HTTP — протокол СѓСЂРѕРІРЅСЏ приложений для распределС�нных, объединС�нных, гиперР�едийных инфорР�ационных систеР�, используеР�ый РІ глобальной инфорР�ационной инициативе Р’СЃРµР�РёСЂРЅРѕР№ паутины СЃ 1990 РіРѕРґР°^[1].

Основные свойства

Основой HTTP является технология «клиент-сервер», то есть предполагается существование:

• Потребителей (клиентов), которые инициируют соединение Р С‘ посылают запрос;
• Поставщиков (серверов), которые ожидают соединения для получения запроса, РїСЂРѕРёР·РІРѕРґСЏС‚ необходиРС�ые действия Р С‘ возвращают обратно сообщение РЎРѓ результатоРС�.

HTTP РІ настоящее РІСЂРµР�СЏ РїРѕРІСЃРµР�естно используется РІРѕ Р’СЃРµР�РёСЂРЅРѕР№ паутине для получения инфорР�ации СЃ веб-сайтов. Р’ 2006 РіРѕРґСѓ РІ Северной РђР�ерике доля HTTP-трафика превысила долю P2P-сетей Рё составила 46 %, РёР· которых почти половина вЂ” это передача потокового видео Рё Р·РІСѓРєР°^[2].

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

РћСЃРЅРѕРІРЅС‹Р� объектоР� Р�анипуляции РІ HTTP является ресурс, РЅР° который указывает URI (Uniform Resource Identifier) РІ запросе клиента. Обычно такиР�Рё ресурсаР�Рё являются хранящиеся РЅР° сервере файлы, РЅРѕ РёР�Рё Р�РѕРіСѓС‚ быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является РІРѕР·Р�ожность указать РІ запросе Рё ответе СЃРїРѕСЃРѕР± представления РѕРґРЅРѕРіРѕ Рё того же ресурса РїРѕ различныР� параР�етраР�: форР�ату, РєРѕРґРёСЂРѕРІРєРµ, языку Рё С‚. Рґ. (РІ частности, для этого используется HTTP-заголовок). Р�Р�енно благодаря РІРѕР·Р�ожности указания СЃРїРѕСЃРѕР±Р° кодирования сообщения клиент Рё сервер Р�РѕРіСѓС‚ РѕР±Р�ениваться двоичныР�Рё данныР�Рё, хотя данный протокол является текстовыР�.

HTTP вЂ” протокол прикладного СѓСЂРѕРІРЅСЏ; аналогичныР�Рё РµР�Сѓ являются FTP Рё SMTP. РћР±Р�ен сообщенияР�Рё РёРґС�С‚ РїРѕ обыкновенной СЃС…РµР�Рµ «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. Р’ отличие РѕС‚ Р�РЅРѕРіРёС… РґСЂСѓРіРёС… протоколов, HTTP РЅРµ сохраняет своего состояния. Это означает отсутствие сохранения РїСЂРѕР�ежуточного состояния Р�ежду параР�Рё «запрос-ответ». РљРѕР�поненты, использующие HTTP, Р�РѕРіСѓС‚ СЃР°Р�остоятельно осуществлять сохранение инфорР�ации Рѕ состоянии, связанной СЃ последниР�Рё запросаР�Рё Рё ответаР�Рё (наприР�ер, «куки» РЅР° стороне клиента, «сессии» РЅР° стороне сервера). Р�раузер, посылающий запросы, Р�ожет отслеживать задержки ответов. Сервер Р�ожет хранить IP-адреса Рё заголовки запросов последних клиентов. Однако СЃР°Р� протокол РЅРµ осведоР�Р»С�РЅ Рѕ предыдущих запросах Рё ответах, РІ РЅС�Р� РЅРµ предусР�отрена внутренняя поддержка состояния, Рє РЅРµР�Сѓ РЅРµ предъявляются такие требования.

Р�ольшинство протоколов предусР�атривает установление TCP-сессии, РІ С…РѕРґРµ которой РѕРґРёРЅ раз РїСЂРѕРёСЃС…РѕРґРёС‚ авторизация, Рё дальнейшие действия выполняются РІ контексте этой авторизации. HTTP же устанавливает отдельную TCP-сессию РЅР° каждый запрос; РІ более РїРѕР·РґРЅРёС… версиях HTTP было разрешено делать несколько запросов РІ С…РѕРґРµ РѕРґРЅРѕР№ TCP-сессии, РЅРѕ браузеры обычно запрашивают только страницу Рё включС�нные РІ РЅРµС� объекты (картинки, каскадные стили Рё С‚. Рї.), Р° затеР� сразу разрывают TCP-сессию. Для поддержки авторизованного (неанониР�РЅРѕРіРѕ) доступа РІ HTTP используются cookies; РїСЂРёС‡С�Р� такой СЃРїРѕСЃРѕР± авторизации позволяет сохранить сессию даже после перезагрузки клиента Рё сервера.

РџСЂРё доступе Рє данныР� РїРѕ FTP или РїРѕ файловыР� протоколаР� тип файла (точнее, тип содержащихся РІ РЅС�Р� данных) определяется РїРѕ расширению РёР�ени файла, что РЅРµ всегда СѓРґРѕР±РЅРѕ. HTTP перед теР�, как передать СЃР°Р�Рё данные, передаС�С‚ заголовок В«Content-Type: тип/подтип», позволяющий клиенту однозначно определить, какиР� образоР� обрабатывать присланные данные. Это особенно важно РїСЂРё работе СЃ CGI-скриптаР�Рё, РєРѕРіРґР° расширение РёР�ени файла указывает РЅРµ РЅР° тип присылаеР�ых клиенту данных, Р° РЅР° необходиР�ость запуска данного файла РЅР° сервере Рё отправки клиенту результатов работы РїСЂРѕРіСЂР°Р�Р�С‹, записанной РІ этоР� файле (РїСЂРё этоР� РѕРґРёРЅ Рё тот же файл РІ зависиР�ости РѕС‚ аргуР�ентов запроса Рё СЃРІРѕРёС… собственных соображений Р�ожет порождать ответы разных типов вЂ” РІ простейшеР� случае картинки РІ разных форР�атах).

Кро�е того, HTTP позволяет клиенту прислать на сервер пара�етры, которые будут переданы запускае�о�у CGI-скрипту. Для этого же в HTML были введены фор�ы.

Перечисленные особенности HTTP позволили создавать поисковые �ашины (первой из которых стала AltaVista, созданная фир�ой DEC), фору�ы и Internet-�агазины. Это ко��ерциализировало �нтернет, появились ко�пании, основны� поле� деятельности которых стало предоставление доступа в �нтернет (провайдеры) и создание сайтов.

Програ��ное обеспечение

Вс� програ��ное обеспечение для работы с протоколо� HTTP разделяется на три большие категории:

• Серверы как основные поставщики услуг хранения Р С‘ обработки инфорРС�ации (обработка запросов);
• Клиенты вЂ” конечные потребители услуг сервера (отправка запроса);
• РџСЂРѕРєСЃРё (посредники) для выполнения транспортных служб.

Для отличия конечных серверов РѕС‚ РїСЂРѕРєСЃРё РІ официальной РґРѕРєСѓР�ентации используется терР�РёРЅ «исходный сервер» (англ. origin server). РћРґРёРЅ Рё тот же РїСЂРѕРіСЂР°Р�Р�ный РїСЂРѕРґСѓРєС‚ Р�ожет РѕРґРЅРѕРІСЂРµР�енно выполнять функции клиента, сервера или посредника РІ зависиР�ости РѕС‚ поставленных задач. Р’ спецификациях протокола HTTP РїРѕРґСЂРѕР±РЅРѕ описывается поведение для каждой РёР· этих ролей.

Клиенты

Первоначально протокол HTTP разрабатывался для доступа к гипертекстовы� доку�ента� Все�ирной паутины. Поэто�у основны�и реализация�и клиентов являются браузеры (агенты пользователя). Для прос�отра сохран�нного содержи�ого сайтов на ко�пьютере без соединения с �нтернето� были приду�аны офлайн-браузеры. При нестабильно� соединении для загрузки больших файлов используются �енеджеры закачек; они позволяют в любое вре�я докачать указанные файлы после потери соединения с веб-серверо�. Некоторые виртуальные атласы (такие как Google Планета Зе�ля и NASA World Wind) тоже используют HTTP.

Нередко протокол HTTP используется програ��а�и для скачивания обновлений.

Целый ко�плекс програ��-роботов используется в поисковых систе�ах �нтернета. Среди них веб-пауки (краулеры), которые производят проход по гиперссылка�, составляют базу данных ресурсов серверов и сохраняют их содержи�ое для дальнейшего анализа.

�сходные серверы

Основные реализации: Apache, Internet Information Services (IIS), nginx, LiteSpeed Web Server^[en] (LSWS), Google Web Server, lighttpd.

Прокси-серверы

Основные реализации: Squid, UserGate, Multiproxy, Naviscope, nginx.

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

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

1. Стартовая строка (англ. Starting line) вЂ” определяет тип сообщения;
2. Заголовки (англ. Headers) вЂ” характеризуют тело сообщения, параР�етры передачи Рё прочие сведения;
3. Тело сообщения (англ. Message Body) вЂ” непосредственно данные сообщения. Обязательно должно отделяться РѕС‚ заголовков пустой строкой.

Тело сообщения Р�ожет отсутствовать, РЅРѕ стартовая строка Рё заголовок являются обязательныР�Рё элеР�ентаР�Рё. Р�сключениеР� является версия 0.9 протокола, Сѓ которой сообщение запроса содержит только стартовую строку, Р° сообщения ответа вЂ” только тело сообщения.

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

Стартовая строка

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

GET URI вЂ” для версии протокола 0.9;

Метод URI HTTP/Версия вЂ” для остальных версий.

Здесь:

• Метод (англ.В Method) вЂ” тип запроса, РѕРґРЅРѕ слово заглавныРС�Р С‘ Р±СѓРєРІР°РС�Р С‘. Р’ версии HTTP 0.9 использовался только Р С�етод GET, СЃРїРёСЃРѕРє Р С�етодов для версии 1.1 представлен ниже.
• URI определяет путь Р С” запрашиваеРС�РѕРС�РЎС“ РґРѕРєСѓРС�енту.
• Версия (англ.В Version) вЂ” пара разделСвЂ�нных точкой цифр. НаприРС�ер: 1.0.

Чтобы запросить страницу данной статьи, клиент должен передать строку (задан всего один заголовок):

Host: ru.wikipedia.org

Стартовая строка ответа сервера РёРС�еет следующий форРС�ат: HTTP/Версия КодСостояния Пояснение, Р С–Р Т‘Р Вµ:

• Версия вЂ” пара разделСвЂ�нных точкой цифр, как Р Р† запросе;
• РљРѕРґ состояния (англ.В Status Code) вЂ” три цифры. Р СџР С• РєРѕРґСѓ состояния определяется дальнейшее содержиРС�РѕРµ сообщения Р С‘ поведение клиента;
• Пояснение (англ.В Reason Phrase) вЂ” текстовое короткое пояснение Р С” РєРѕРґСѓ ответа для пользователя. Никак Р Р…Р Вµ влияет Р Р…Р В° сообщение Р С‘ является необязательныРС�.

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

HTTP/1.0 200 OK

Методы

Метод HTTP (англ. HTTP Method) вЂ” последовательность РёР· любых СЃРёР�волов, РєСЂРѕР�Рµ управляющих Рё разделителей, указывающая РЅР° РѕСЃРЅРѕРІРЅСѓСЋ операцию над ресурсоР�. Обычно Р�етод представляет СЃРѕР±РѕР№ короткое английское слово, записанное заглавныР�Рё Р±СѓРєРІР°Р�Рё. Обратите РІРЅРёР�ание, что название Р�етода чувствительно Рє регистру.

Сервер Р С�ожет использовать любые Р С�етоды, Р Р…Р Вµ существует обязательных Р С�етодов для сервера или клиента. Если сервер Р Р…Р Вµ распознал указанный клиентоРС� Р С�етод, то РѕРЅ должен вернуть статус 501 (Not Implemented). Если серверу Р С�етод известен, Р Р…Р С• РѕРЅ неприРС�ениРС� Р С” конкретноРС�РЎС“ ресурсу, то возвращается сообщение РЎРѓ РєРѕРґРѕРС� 405 (Method Not Allowed). Р’ РѕР±РѕРёС… случаях серверу следует включить Р Р† сообщение ответа заголовок Allow РЎРѓР С• СЃРїРёСЃРєРѕРС� поддерживаеРС�ых Р С�етодов.

РљСЂРѕРС�Р Вµ Р С�етодов GET Р С‘ HEAD, часто РїСЂРёРС�еняется Р С�етод POST.

OPTIONS

�спользуется для определения РІРѕР·РС�ожностей веб-сервера или параРС�етров соединения для конкретного ресурса. Р’ ответ серверу следует включить заголовок Allow РЎРѓР С• СЃРїРёСЃРєРѕРС� поддерживаеРС�ых Р С�етодов. Также Р Р† заголовке ответа Р С�ожет включаться инфорРС�ация Р С• поддерживаеРС�ых расширениях.

Предполагается, что запрос клиента �ожет содержать тело сообщения для указания интересующих его сведений. Фор�ат тела и порядок работы с ни� в настоящий �о�ент не определ�н; сервер пока должен его игнорировать. Аналогичная ситуация и с тело� в ответе сервера.

Для того, чтобы узнать РІРѕР·РС�ожности всего сервера, клиент должен указать Р Р† URI Р·РІСвЂ�здочку вЂ” Р’В«*Р’В». Запросы Р’В«OPTIONS * HTTP/1.1Р’В» Р С�РѕРіСѓС‚ также РїСЂРёРС�еняться для проверки работоспособности сервера (аналогично «пингованию») Р С‘ тестирования Р Р…Р В° предРС�ет поддержки сервероРС� протокола HTTP версии 1.1.

Результат выполнения этого �етода не кэшируется.

GET

�спользуется для запроса содержиРС�РѕРіРѕ указанного ресурса. Р РЋ РїРѕРС�ощью Р С�етода GET Р С�ожно также начать какой-либо процесс. Р’ этоРС� случае Р Р† тело ответного сообщения следует включить инфорРС�ацию Р С• С…РѕРґРµ выполнения процесса.

Клиент Р С�ожет передавать параРС�етры выполнения запроса Р Р† URI целевого ресурса после СЃРёРС�вола Р’В«?Р’В»:
GET /path/resource?param1=value1&param2=value2 HTTP/1.1

Согласно стандарту HTTP, запросы типа GET считаются РёРґРµРС�потентныРС�Р С‘^[3]

РљСЂРѕРС�Р Вµ обычного Р С�етода GET, различают ещСвЂ�

• Условный GET вЂ” содержит заголовки If-Modified-Since, If-Match, If-Range Р С‘ подобные;
• Частичный GET вЂ” содержит Р Р† запросе Range.

Порядок выполнения подобных запросов определ�н стандарта�и отдельно.

HEAD

Аналогичен Р С�етоду GET, Р В·Р В° исключениеРС� того, что Р Р† ответе сервера отсутствует тело. Запрос HEAD обычно РїСЂРёРС�еняется для извлечения Р С�етаданных, проверки наличия ресурса (валидация URL) Р С‘ чтобы узнать, Р Р…Р Вµ РёР·РС�енился ли РѕРЅ РЎРѓ Р С�РѕРС�ента последнего обращения.

Заголовки ответа Р�РѕРіСѓС‚ кэшироваться. РџСЂРё несовпадении Р�етаданных ресурса СЃ соответствующей инфорР�ацией РІ кэше вЂ” РєРѕРїРёСЏ ресурса РїРѕР�ечается как устаревшая.

POST

РџСЂРёРС�еняется для передачи пользовательских данных заданноРС�РЎС“ ресурсу. НаприРС�ер, Р Р† блогах посетители обычно Р С�РѕРіСѓС‚ вводить СЃРІРѕРё РєРѕРС�Р С�ентарии Р С” записяРС� Р Р† HTML-форРС�РЎС“, после чего РѕРЅРё передаются серверу Р С�етодоРС� POST Р С‘ РѕРЅ РїРѕРС�ещает РёС… Р Р…Р В° страницу. РџСЂРё этоРС� передаваеРС�ые данные (Р Р† РїСЂРёРС�ере РЎРѓ блогаРС�Рё вЂ” текст РєРѕРС�Р С�ентария) включаются Р Р† тело запроса. Аналогично РЎРѓ РїРѕРС�ощью Р С�етода POST обычно загружаются файлы Р Р…Р В° сервер.

Р’ отличие РѕС‚ Р С�етода GET, Р С�етод POST Р Р…Р Вµ считается РёРґРµРС�потентныРС�^[3], то есть Р С�ногократное повторение РѕРґРЅРёС… Р С‘ тех же запросов 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 Р Р…Р Вµ кэшируются.

PATCH

Аналогично PUT, но при�еняется только к фраг�енту ресурса.

DELETE

Удаляет указанный ресурс.

TRACE

Возвращает полученный запрос так, что клиент �ожет увидеть, какую инфор�ацию про�ежуточные серверы добавляют или из�еняют в запросе.

CONNECT

Преобразует соединение запроса в прозрачный TCP/IP-туннель, обычно чтобы содействовать установлению защищ�нного SSL-соединения через нешифрованный прокси.

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

Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из тр�х цифр^[4]. Первая цифра указывает на класс состояния. За кодо� ответа обычно следует отдел�нная пробело� поясняющая фраза на английско� языке, которая разъясняет человеку причину и�енно такого ответа. При�еры:

201 Webpage Created
403 Access allowed only for registered users
507 Insufficient Storage

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

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

Заголовки

Заголовки HTTP (англ. HTTP Headers) вЂ” это строки РІ HTTP-сообщении, содержащие разделС�РЅРЅСѓСЋ двоеточиеР� пару параР�етр-значение. ФорР�ат заголовков соответствует общеР�Сѓ форР�ату заголовков текстовых сетевых сообщений ARPA (СЃР�. RFC 822). Заголовки должны отделяться РѕС‚ тела сообщения хотя Р±С‹ РѕРґРЅРѕР№ пустой строкой.

При�еры заголовков:

Server: Apache/2.2.11 (Win32) PHP/5.3.0
Last-Modified: Sat, 16 Jan 2010 21:16:42 GMT
Content-Type: text/plain; charset=windows-1251
Content-Language: ru

Р’ РїСЂРёР�ере выше каждая строка представляет СЃРѕР±РѕР№ РѕРґРёРЅ заголовок. РџСЂРё этоР� то, что находится РґРѕ двоеточия, называется РёР�енеР� (англ. name), Р° что после него вЂ” значениеР� (англ. value).

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

1. General Headers («Основные заголовки») вЂ” Р�РѕРіСѓС‚ включаться РІ любое сообщение клиента Рё сервера;
2. Request Headers («Заголовки запроса») вЂ” используются только РІ запросах клиента;
3. Response Headers («Заголовки ответа») вЂ” только для ответов РѕС‚ сервера;
4. Entity Headers («Заголовки сущности») вЂ” сопровождают каждую сущность сообщения.

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

Р’СЃРµ необходиРС�ые для функционирования HTTP заголовки описаны Р Р† основных RFC. Если Р Р…Р Вµ хватает существующих, то Р С�ожно вводить СЃРІРѕРё. Традиционно Р С” РёРС�енаРС� таких дополнительных заголовков добавляют префикс Р’В«X-Р’В» для избежания конфликта РёРС�РЎвЂ�Р Р… РЎРѓ РІРѕР·РС�ожно существующиРС�Р С‘. НаприРС�ер, как Р Р† заголовках X-Powered-By или X-Cache. Некоторые разработчики используют СЃРІРѕРё индивидуальные префиксы. РџСЂРёРС�ераРС�Р С‘ таких заголовков Р С�РѕРіСѓС‚ служить Ms-Echo-Request Р С‘ Ms-Echo-Reply, введСвЂ�нные корпорацией Microsoft для расширения WebDAV.

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

Тело HTTP-сообщения (message-body), если РѕРЅРѕ присутствует, используется для передачи тела объекта, связанного РЎРѓ запросоРС� или ответоРС�. Тело сообщения отличается РѕС‚ тела объекта (entity-body) только Р Р† тоРС� случае, РєРѕРіРґР° РїСЂРёРС�еняется кодирование передачи, что указывается полеРС� заголовка Transfer-Encoding.

message-body = entity-body
| <entity-body закодировано согласно
Transfer-Encoding>

Поле Transfer-Encoding должно использоваться для указания любого кодирования передачи, РїСЂРёРС�енСвЂ�РЅРЅРѕРіРѕ приложениеРС� Р Р† целях гарантирования безопасной Р С‘ правильной передачи сообщения. Поле Transfer-Encoding вЂ” это свойство сообщения, Р В° Р Р…Р Вµ объекта, Р С‘, такиРС� образоРС�, Р С�ожет быть добавлено или удалено любыРС� приложениеРС� Р Р† цепочке запросов/ответов.

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

Присутствие тела сообщения Р Р† запросе РѕС‚РС�ечается добавлениеРС� Р С” заголовкаРС� запроса поля заголовка Content-Length или Transfer-Encoding. Тело сообщения Р С�ожет Р±С‹С‚СЊ добавлено Р Р† запрос, только РєРѕРіРґР° Р С�етод запроса допускает тело объекта.

Включается или Р Р…Р Вµ включается тело сообщения Р Р† сообщение ответа вЂ” зависит как РѕС‚ Р С�етода запроса, так Р С‘ РѕС‚ РєРѕРґР° состояния ответа. Р’СЃРµ ответы Р Р…Р В° запрос РЎРѓ Р С�етодоРС� HEAD Р Р…Р Вµ должны включать тело сообщения, даже если присутствуют поля заголовка объекта (entity-header), заставляющие поверить Р Р† присутствие объекта. Никакие ответы РЎРѓ РєРѕРґР°РС�Р С‘ состояния 1xx (Р�нфорРС�ационные), 204 (Нет содержиРС�РѕРіРѕ, No Content), Р С‘ 304 (Р СњР Вµ Р С�одифицирован, Not Modified) Р Р…Р Вµ должны содержать тела сообщения. Р’СЃРµ РґСЂСѓРіРёРµ ответы содержат тело сообщения, даже если РѕРЅРѕ РёРС�еет нулевую длину.

При�еры диалогов HTTP

GET /wiki/страница HTTP/1.1
Host: ru.wikipedia.org
User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Accept: text/html
Connection: close
(пустая строка)  

HTTP/1.1 200 OK
Date: Wed, 11 Feb 2009 11:20:59 GMT
Server: Apache
X-Powered-By: PHP/5.2.4-2ubuntu5wm1
Last-Modified: Wed, 11 Feb 2009 11:20:59 GMT
Content-Language: ru
Content-Type: text/html; charset=utf-8
Content-Length: 1234
Connection: close
(пустая строка)
(запрошенная страница в HTML)

GET /about.html HTTP/1.1
Host: example.org
User-Agent: MyLonelyBrowser/5.0

HTTP/1.x 301 Moved Permanently
Location: http://example.com/about.html#contacts
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.4
Content-Type: text/html; charset=windows-1251
Content-Length: 110
(пустая строка)
<html><body><a href="http://example.com/about.html#contacts">Click here</a></body></html>

GET / HTTP/1.1
Host: example.com
User-Agent: MyLonelyBrowser/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: ru,en-us;q=0.7,en;q=0.3
Accept-Charset: windows-1251,utf-8;q=0.7,*;q=0.7

HTTP/1.x 302 Found
Location: http://example.ru/
Cache-Control: private
Date: Thu, 19 Feb 2009 11:08:01 GMT
Server: Apache/2.2.6
Content-Type: text/html; charset=windows-1251
Content-Length: 82
(пустая строка)
<html><body><a href="http://example.ru">Example Corp.</a></body></html>

GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Referer: http://example.org/

HTTP/1.1 200 OK
Date: Thu, 19 Feb 2009 12:27:04 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Content-Type: video/x-msvideo
Content-Length: 160993792
Accept-Ranges: bytes
Connection: close
(пустая строка)
(двоичное содержи�ое всего файла)

GET /conf-2009.avi HTTP/1.0
Host: example.org
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
Range: bytes=88080384-
Referer: http://example.org/

HTTP/1.1 206 Partial Content
Date: Thu, 19 Feb 2009 12:27:08 GMT
Server: Apache/2.2.3
Last-Modified: Wed, 18 Jun 2003 16:05:58 GMT
ETag: "56d-9989200-1132c580"
Accept-Ranges: bytes
Content-Range: bytes 88080384-160993791/160993792
Content-Length: 72913408
Connection: close
Content-Type: video/x-msvideo
(пустая строка)
(двоичное содержи�ое от 84-го �егабайта)

GET /conf-2009.avi HTTP/1.0
Range: bytes=64397516-80496894

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Range: bytes 64397516-80496894/160993792
Content-Length: 16099379
(пустая строка)
(двоичное содержи�ое 4-й части)

С�. также частичные GET, байтовые диапазоны, ответ 206, ответ 416.

Основные �еханиз�ы протокола

Частичные GET

HTTP позволяет запросить Р Р…Р Вµ сразу РІСЃСвЂ� содержиРС�РѕРµ ресурса, Р В° только указанный фрагРС�ент. Такие запросы называются частичные GET; РІРѕР·РС�ожность РёС… выполнения необязательна (Р Р…Р С• желательна) для серверов. Частичные GET Р Р† РѕСЃРЅРѕРІРЅРѕРС� используются для докачки файлов Р С‘ быстрого параллельного скачивания Р Р† нескольких потоках. Некоторые РїСЂРѕРіСЂР°РС�Р С�С‹ скачивают заголовок архива, выводят пользователю внутреннюю структуру, Р В° потоРС� уже запрашивают фрагРС�енты РЎРѓ указанныРС�Р С‘ элеРС�ентаРС�Р С‘ архива.

Для получения фрагРС�ента клиент посылает серверу запрос РЎРѓ заголовкоРС� Range, указывая Р Р† Р Р…РЎвЂ�Р С� необходиРС�ые байтовые диапазоны. Если сервер Р Р…Р Вµ РїРѕРЅРёРС�ает частичные запросы (игнорирует заголовок Range), то РѕРЅ вернСвЂ�С‚ РІСЃСвЂ� содержиРС�РѕРµ РЎРѓР С• статусоРС� 200, как Р С‘ РїСЂРё обычноРС� GET. Р’ случае успешного выполнения сервер возвращает РІРС�есто РєРѕРґР° 200 ответ РЎРѓР С• статусоРС� 206 (Partial Content), включая Р Р† ответ заголовок Content-Range. РЎР°РС�Р С‘ фрагРС�енты Р С�РѕРіСѓС‚ быть переданы РґРІСѓРС�РЎРЏ СЃРїРѕСЃРѕР±Р°РС�Р С‘:

• Р’ ответе РїРѕРС�ещается заголовок Content-Range РЎРѓ указаниеРС� байтовых диапазонов. Р’ соответствии РЎРѓ РЅРёРС�Р С‘ фрагРС�енты последовательно РїРѕРС�ещаются Р Р† РѕСЃРЅРѕРІРЅРѕРµ тело. РџСЂРё этоРС� Content-Length должен соответствовать СЃСѓРС�Р С�арноРС�РЎС“ РѕР±СЉСвЂ�Р С�РЎС“ всего тела;
• Сервер указывает Р С�едиатип multipart/byteranges для РѕСЃРЅРѕРІРЅРѕРіРѕ содержиРС�РѕРіРѕ Р С‘ передаСвЂ�С‚ фрагРС�енты, указывая соответствующий Content-Range для каждого элеРС�ента (РЎРѓР С�. также «Множественное содержиРС�ое»^{[в‡Ё]}).

Условные GET

Метод GET РёР·РС�еняется Р Р…Р В° «условный GETР’В», если сообщение запроса включает Р Р† себя поле заголовка If-Modified-Since. Р’ ответ Р Р…Р В° «условный GETР’В» тело запрашиваеРС�РѕРіРѕ ресурса передаСвЂ�тся, только если РѕРЅ РёР·РС�енялся после даты, указанной Р Р† заголовке If-Modified-Since. АлгоритРС� определения этого включает Р Р† себя следующие случаи:

• Если статус ответа Р Р…Р В° запрос будет отличаться РѕС‚ Р’В«200 OKР’В» или дата, указанная Р Р† поле заголовка Р’В«If-Modified-SinceР’В», некорректна, ответ будет идентичен ответу Р Р…Р В° обычный запрос GET.
• Если после указанной даты ресурс РёР·РС�енялся, ответ будет также идентичен ответу Р Р…Р В° обычный запрос GET.
• Если ресурс Р Р…Р Вµ РёР·РС�енялся после указанной даты, сервер вернет статус Р’В«304 Not ModifiedР’В».

�спользование �етода «условный GET» направлено на разгрузку сети, так как он позволяет не передавать по сети избыточную инфор�ацию.

Согласование содержи�ого

Согласование содержиР�РѕРіРѕ (англ. Content Negotiation) вЂ” Р�еханизР� автоР�атического определения необходиР�РѕРіРѕ ресурса РїСЂРё наличии нескольких разнотипных версий РґРѕРєСѓР�ента. СубъектаР�Рё согласования Р�РѕРіСѓС‚ быть РЅРµ только ресурсы сервера, РЅРѕ Рё возвращаеР�ые страницы СЃ сообщенияР�Рё РѕР± ошибках (403, 404 Рё С‚. Рї.).

Различают два основных типа согласований:

• УправляеРС�РѕРµ сервероРС� (англ.В server-driven).
• УправляеРС�РѕРµ клиентоРС� (англ.В agent-driven).

Одновре�енно �огут быть использованы оба типа или каждый из них по отдельности.

Р’ РѕСЃРЅРѕРІРЅРѕР№ спецификации РїРѕ протоколу (RFC 2616) также выделяется так называеР�РѕРµ прозрачное согласование (англ. transparent negotiation) как предпочтительный вариант РєРѕР�бинирования РѕР±РѕРёС… типов. Последний Р�еханизР� РЅРµ следует путать СЃ независиР�РѕР№ технологией Transparent Content Negotiation (TCN, «Прозрачное согласование содержиР�РѕРіРѕВ», СЃР�. RFC 2295), которая РЅРµ является частью протокола HTTP, РЅРѕ Р�ожет использоваться СЃ РЅРёР�. РЈ РѕР±РѕРёС… существенное различие РІ принципе работы Рё СЃР°Р�РѕР� значении слова «прозрачное» (transparent). Р’ спецификации РїРѕ HTTP РїРѕРґ прозрачностью подразуР�евается, что процесс РЅРµ Р·Р°Р�етен для клиента Рё сервера, Р° РІ технологии TCN прозрачность означает доступность полного СЃРїРёСЃРєР° вариантов ресурса для всех участников процесса доставки данных.

Управляе�ое серверо�

РџСЂРё наличии нескольких версий ресурса сервер Р С�ожет анализировать заголовки запроса клиента, чтобы выдать, Р С—Р С• его Р С�нению, наиболее подходящую. Р’ РѕСЃРЅРѕРІРЅРѕРС� анализируются заголовки Accept, Accept-Charset, Accept-Encoding, Accept-Languages Р С‘ User-Agent. Серверу желательно включать Р Р† ответ заголовок Vary РЎРѓ указаниеРС� параРС�етров, Р С—Р С• которыРС� различается содержиРС�РѕРµ Р С—Р С• запрашиваеРС�РѕРС�РЎС“ URI.

Географическое положение клиента �ожно определить по удал�нно�у IP-адресу. Это воз�ожно за сч�т того что IP-адреса, как и до�енные и�ена, регистрируются на конкретного человека или организацию. При регистрации указывается регион, в которо� будет использоваться желае�ое адресное пространство. Эти данные общедоступны, и в �нтернете �ожно найти соответствующие свободно распространяе�ые базы данных и готовые програ��ные �одули для работы с ни�и (следует ориентироваться на ключевые слова «Geo IP»).

Следует по�нить что такой �етод способен определить �естоположение �акси�у� с точностью до города (отсюда определяется и страна). При это� инфор�ация актуальна только на �о�ент регистрации адресного пространства. Напри�ер, если �осковский провайдер зарегистрирует диапазон адресов с указание� Москвы и начн�т предоставлять доступ клиента� из ближайшего Под�осковья, то его абоненты �огут на некоторых сайтах наблюдать, что они из Москвы, а не из Красногорска или Дзержинского.

Управляе�ое серверо� согласование и�еет несколько недостатков:

• Сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, Р Р…Р С• Р Р…Р Вµ Р С�ожет знать точно, что РёРС�енно нужно Р Р† данный Р С�РѕРС�ент (наприРС�ер, версия Р Р…Р В° СЂСѓСЃСЃРєРѕРС� языке или английскоРС�).
• Заголовков РіСЂСѓРїРїС‹ Accept передаСвЂ�тся Р С�РЅРѕРіРѕ, Р В° ресурсов РЎРѓ несколькиРС�Р С‘ вариантаРС�Рё вЂ” Р С�ало. Р пїЅР В·-Р В·Р В° этого оборудование испытывает избыточную нагрузку.
• ОбщеРС�РЎС“ кэшу СЃРѕР·РґР°СвЂ�тся ограничение РІРѕР·РС�ожности выдавать РѕРґРёРЅ Р С‘ тот же ответ Р Р…Р В° идентичные запросы РѕС‚ разных пользователей.
• Передача заголовков Accept также Р С�ожет раскрывать некоторые сведения Р С• его предпочтениях, таких как используеРС�ые языки, браузер, РєРѕРґРёСЂРѕРІРєР°.

Управляе�ое клиенто�

Р’ данноРС� случае тип содержиРС�РѕРіРѕ определяется только Р Р…Р В° стороне клиента. Для этого сервер возвращает Р Р† ответе РЎРѓ РєРѕРґРѕРС� состояния 300 (Multiple Choices) или 406 (Not Acceptable) СЃРїРёСЃРѕРє вариантов, среди которых пользователь выбирает подходящий. УправляеРС�РѕРµ клиентоРС� согласование хорошо, РєРѕРіРґР° содержиРС�РѕРµ различается Р С—Р С• СЃР°РС�С‹РС� частыРС� параРС�етраРС� (наприРС�ер, Р С—Р С• языку Р С‘ РєРѕРґРёСЂРѕРІРєРµ) Р С‘ используется публичный РєСЌС€.

РћСЃРЅРѕРІРЅРѕР№ недостаток вЂ” лишняя нагрузка, так как приходится делать дополнительный запрос, чтобы получить нужное содержиР�РѕРµ.

Прозрачное согласование

Данное согласование полностью прозрачно для клиента и сервера. В данно� случае используется общий кэш, в которо� содержится список вариантов, как для управляе�ого клиенто� согласования. Если кэш пони�ает все эти варианты, то он са� делает выбор, как при управляе�о� серверо� согласовании. Это снижает нагрузки с исходного сервера и исключает дополнительный запрос со стороны клиента.

В основной спецификации по протоколу HTTP �еханиз� прозрачного согласования подробно не описан.

Множественное содержи�ое

Протокол HTTP поддерживает передачу нескольких сущностей Р Р† пределах РѕРґРЅРѕРіРѕ сообщения. РџСЂРёС‡СвЂ�Р С� сущности Р С�РѕРіСѓС‚ передаваться Р Р…Р Вµ только Р Р† РІРёРґРµ одноуровневой последовательности, Р Р…Р С• Р С‘ Р Р† РІРёРґРµ иерархии РЎРѓ вложениеРС� элеРС�ентов РґСЂСѓРі Р Р† РґСЂСѓРіР°. Для обозначения Р С�ножественного содержиРС�РѕРіРѕ используются Р С�едиатипы multipart/*. Работа РЎРѓ такиРС�Р С‘ типаРС�Р С‘ осуществляется Р С—Р С• общиРС� правилаРС�, описанныРС� Р Р† RFC 2046 (если РёРЅРѕРµ Р Р…Р Вµ определено конкретныРС� Р С�едиатипоРС�). Если получателю Р Р…Р Вµ известно как работать РЎРѓ типоРС�, то РѕРЅ обрабатывает его так же, как multipart/mixed.

Пара�етр boundary означает разделитель �ежду различны�и типа�и передавае�ых сообщений. Напри�ер, передавае�ый из фор�ы пара�етр DestAddress переда�т значение адреса e-mail, а следующий за ни� эле�ент AttachedFile1 отправляет двоичное содержи�ое изображения фор�ата .jpg

Р РЋР С• стороны сервера сообщения РЎРѓР С• Р С�ножественныРС� содержиРС�С‹РС� Р С�РѕРіСѓС‚ посылаться Р Р† ответ Р Р…Р В° частичные GET РїСЂРё запросе нескольких фрагРС�ентов ресурса. Р’ этоРС� случае используется Р С�едиатип multipart/byteranges.

Р РЋР С• стороны клиента РїСЂРё отправке HTML-форРС�С‹ чаще всего пользуются Р С�етодоРС� POST. Типичный РїСЂРёРС�ер: страницы отправки электронных РїРёСЃРµРС� РЎРѓР С• вложенныРС�Р С‘ файлаРС�Р С‘. РџСЂРё отправке такого РїРёСЃСЊРС�Р В° браузер форРС�ирует сообщение типа multipart/form-data, интегрируя Р Р† него как отдельные части, введСвЂ�нные пользователеРС�, теРС�РЎС“ РїРёСЃСЊРС�Р В°, адрес получателя, СЃР°РС� текст Р С‘ вложенные файлы:

POST /send-message.html HTTP/1.1
Host: mail.example.com
Referer: http://mail.example.com/send-message.html
User-Agent: BrowserForDummies/4.67b
Content-Type: multipart/form-data; boundary="Asrf456BGe4h"
Content-Length: (су��арный объ��, включая дочерние заголовки)
Connection: keep-alive
Keep-Alive: 300
(пустая строка)
(отсутствующая преа�була)
--Asrf456BGe4h
Content-Disposition: form-data; name="DestAddress"
(пустая строка)
brutal-vasya@example.com—Asrf456BGe4h
Content-Disposition: form-data; name="MessageTitle"
(пустая строка)
Я негодую—Asrf456BGe4h
Content-Disposition: form-data; name="MessageText"
(пустая строка)
Привет, Василий! Твой ручной лев, которого ты оставил
у �еня на прошлой неделе, разодрал весь �ой диван.
Пожалуйста, забери его скорее!
Во вложении две фотки с последствия�и.
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержи�ое первой фотографии)
--Asrf456BGe4h
Content-Disposition: form-data; name="AttachedFile2"; filename="horror-photo-2.jpg"
Content-Type: image/jpeg
(пустая строка)
(двоичное содержи�ое второй фотографии)
--Asrf456BGe4h--
(отсутствующий эпилог)

Р’ РїСЂРёРС�ере Р Р† заголовках Content-Disposition параРС�етр name соответствует атрибуту name Р Р† HTML-тегах <INPUT> Р С‘ <TEXTAREA>. ПараРС�етр filename равен РёСЃС…РѕРґРЅРѕРС�РЎС“ РёРС�ени файла Р Р…Р В° РєРѕРС�пьютере пользователя. Р вЂ�олее подробная инфорРС�ация Р С• форРС�ировании HTML-форРС� Р С‘ вложении файлов Р Р† RFC 1867.

�стория развития

HTTP/0.9

HTTP был предложен в �арте 1991 года Ти�о� �ернерсо�-Ли, работавши� тогда в CERN, как �еханиз� для доступа к доку�ента� в �нтернете и облегчения навигации посредство� использования гипертекста. Са�ая ранняя версия протокола HTTP/0.9 была впервые опубликована в январе 1992 года (хотя реализация датируется 1990 годо�). Спецификация протокола привела к упорядочению правил взаи�одействия �ежду клиента�и и сервера�и HTTP, а также ч�тко�у разделению функций �ежду эти�и дву�я ко�понента�и. �ыли задоку�ентированы основные синтаксические и се�антические положения.

HTTP/1.0

В �ае 1996 года для практической реализации HTTP был выпущен инфор�ационный доку�ент RFC 1945, что послужило основой для реализации большинства ко�понентов HTTP/1.0.

HTTP/1.1

Совре�енная версия протокола; принята в июне 1999 года^[5]. Новы� в этой версии был режи� «постоянного соединения»: TCP-соединение �ожет оставаться открыты� после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать инфор�ацию об и�ени хоста, к которо�у он обращается, что сделало воз�ожной более простую организацию виртуального хостинга.

HTTP/2

Основная статья: HTTP/2

11 февраля 2015 РіРѕРґР° опубликованы финальные версии черновика следующей версии протокола. Р’ отличие РѕС‚ предыдущих версий, протокол HTTP/2 является бинарныР�. Среди ключевых особенностей: Р�ультиплексирование запросов, расстановка приоритетов для запросов, сжатие заголовков, загрузка нескольких элеР�ентов параллельно посредствоР� РѕРґРЅРѕРіРѕ TCP-соединения, поддержка проактивных push-уведоР�лений СЃРѕ стороны сервера^[6].

HTTP/3

HTTP/3 вЂ” предлагаеР�ый последователь HTTP/2^[7][8], который уже используется РІ Веб РЅР° РѕСЃРЅРѕРІРµ UDP РІР�есто TCP РІ качестве транспортного протокола. Как Рё HTTP/2, РѕРЅ РЅРµ объявляет устаревшиР�Рё предыдущие основные версии протокола. Поддержка HTTP/3 была добавлена РІ Cloudflare Рё Google Chrome РІ сентябре 2019 РіРѕРґР°^[9][10] Рё Р�ожет быть включена РІ стабильных версиях Chrome Рё Firefox^[11].

С�. также

• РЎРїРёСЃРѕРє РєРѕРґРѕРІ состояния HTTP
• Заголовки HTTP (СЃРїРёСЃРѕРє):
  • Referer
  • User-Agent
• Cookie
• Дайджест-аутентификация
• HTTP/2
• HTTPS

При�ечания

Ссылки

• Медиафайлы Р С—Р С• теРС�Р Вµ HTTP Р Р…Р В° Викискладе
• RFC 1945 вЂ” HTTP/1.0 (Май 1996), включает версию 0.9
• RFC 2616 вЂ” HTTP/1.1 (�юнь 1999); РЎРѓР С�. также Р Р† РІРёРґРµ PostScript Р С‘ PDF;
• httpbis-http2-17 вЂ” HTTP/2 (11 февраля 2015) Окончательная спецификация
• «Разъяснение http/2Р’В» Даниэль Штенберг (СЂСѓСЃ.)
• Найденные опечатки Р Р† спецификации HTTP/1.1
• [www.lib.ru/WEBMASTER/rfc2068/ Перевод спецификации HTTP/1.1]
• Первоначальный HTTP 0.9 РўРёРС�Р В° Р вЂ�ернерса-Ли (написан Р С‘ издан Р Р† 1991 РіРѕРґСѓ)
• Ранняя версия РёСЃС…РѕРґРЅРѕРіРѕ черновика версии 1.0 1992 РіРѕРґР° РўРёРС�Р В° Р вЂ�ернерса-Ли
• РџСЂРёРС�ер последовательности HTTP-РѕР±РС�ена Архивная РєРѕРїРёСЏ РѕС‚ 5 августа 2012 Р Р…Р В° Wayback Machine Р С�ежду браузероРС� Р С‘ сервероРС�
• Функционирование HTTP-сервера