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^{[англ.]} (LSWS), Google Web Server, lighttpd.

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

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

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

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

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

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

Метод 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.

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

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

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

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

�спользуется для запроса содержиРС�РѕРіРѕ указанного ресурса. Р РЋ РїРѕРС�ощью Р С�етода 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.

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

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

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

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

Р’ отличие РѕС‚ Р С�етода GET, Р С�етод POST Р Р…Р Вµ считается РёРґРµРС�потентныРС�^[3], то есть Р С�ногократное повторение РѕРґРЅРёС… Р С‘ тех же запросов POST Р С�ожет возвращать разные результаты (наприРС�ер, после каждой отправки РєРѕРС�Р С�ентария будет появляться очередная РєРѕРїРёСЏ этого РєРѕРС�Р С�ентария).

РџСЂРё результате выполнения 200 (Ok) Р Р† тело ответа следует включить сообщение РѕР± итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) РЎРѓ указаниеРС� URI РЅРѕРІРѕРіРѕ ресурса Р Р† заголовке Location.

Сообщение ответа сервера Р Р…Р В° выполнение Р С�етода POST Р Р…Р Вµ кэшируется.

РџСЂРёРС�еняется для загрузки содержиРС�РѕРіРѕ запроса Р Р…Р В° указанный Р Р† запросе URI. Если Р С—Р С• заданноРС�РЎС“ URI Р Р…Р Вµ существует ресурса, то сервер СЃРѕР·РґР°СвЂ�С‚ его Р С‘ возвращает статус 201 (Created). Если же ресурс был РёР·РС�енСвЂ�Р Р…, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер Р Р…Р Вµ должен игнорировать некорректные заголовки Content-*, передаваеРС�ые клиентоРС� РІРС�есте РЎРѓ сообщениеРС�. Если какой-то РёР· этих заголовков Р Р…Р Вµ Р С�ожет быть распознан или недопустиРС� РїСЂРё текущих условиях, то необходиРС�Р С• вернуть РєРѕРґ ошибки 501 (Not Implemented).

ФундаРС�ентальное различие Р С�етодов POST Р С‘ PUT заключается Р Р† РїРѕРЅРёРС�ании предназначений URI ресурсов. Метод POST предполагает, что Р С—Р С• указанноРС�РЎС“ URI будет производиться обработка передаваеРС�РѕРіРѕ клиентоРС� содержиРС�РѕРіРѕ. �спользуя PUT, клиент предполагает, что загружаеРС�РѕРµ содержиРС�РѕРµ соответствует находящеРС�СѓСЃСЏ Р С—Р С• данноРС�РЎС“ URI ресурсу.

Сообщения ответов сервера Р Р…Р В° Р С�етод PUT Р Р…Р Вµ кэшируются.

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

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

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

Преобразует соединение запроса в прозрачный 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) Р Р…Р Вµ должны содержать тела сообщения. Р’СЃРµ РґСЂСѓРіРёРµ ответы содержат тело сообщения, даже если РѕРЅРѕ РёРС�еет нулевую длину.

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.

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

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

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

Метод 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/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-сервера