Просмотр кода страницы HTTP

{{Карточка протокола
|Аббр = HTTP
|Название = Hypertext Transfer Protocol
|Уровень = Прикладной
|Семейство = [[стек протоколов TCP/IP|TCP/IP]]
|Создан = [[1990 год]]у
|Порт = 80/[[TCP]]
|Спецификация = 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 HTTP Server|Apache]], [[IIS]], [[nginx]], [[Google Web Server]] и др.
|Сайт = https://www.w3.org/Protocols/
|Новая версия:=HTTP-3}}
'''HTTP''' ({{lang-en|Hypertext Transfer Protocol}} — «протокол передачи [[гипертекст]]а») — [[сетевой протокол]] [[Протоколы прикладного уровня|прикладного уровня]], который изначально предназначался для получения с серверов гипертекстовых документов в формате HTML, а с течением времени стал универсальным средством взаимодействия между узлами как [[Всемирная паутина|Всемирной паутины]], так и изолированных веб-инфраструктур.

Определение по основным документациям: HTTP — протокол уровня приложений для распределённых, объединённых, гипермедийных информационных систем, используемый в глобальной информационной инициативе Всемирной паутины с 1990 года<ref>См. раздел «Abstract» в самом начале RFC 1945 (1996 год) и RFC 9112 (2022-й).</ref>.

== Основные свойства ==
Основой HTTP является [[Клиент-сервер|технология «клиент-сервер»]], то есть предполагается существование:
* потребителей ([[Клиент (программный)|клиентов]]), которые инициируют соединение и посылают запрос;
* поставщиков ([[Сервер (приложение)|серверов]]), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.

HTTP в настоящее время повсеместно используется во [[Всемирная паутина|Всемирной паутине]] для получения информации с [[веб-сайт]]ов. В [[2006 год]]у в [[Северная Америка|Северной Америке]] доля HTTP-[[Информация|трафика]] превысила долю [[Пиринговые сети|P2P-сетей]] и составила 46 %, из которых почти половина — это передача [[Потоковое мультимедиа|потокового]] видео и звука<ref>[http://net.compulenta.ru/322974/ Объём HTTP-трафика впервые превысил P2P] {{Wayback|url=http://net.compulenta.ru/322974/ |date=20071222181125 }} // Компьюлента, 22 июня 2007 ([http://www.ellacoya.com/news/pdf/2007/NXTcommEllacoyaMediaAlert.pdf Официальный документ от Ellacoya Networks] {{Wayback|url=http://www.ellacoya.com/news/pdf/2007/NXTcommEllacoyaMediaAlert.pdf |date=20070622153904 }}).</ref>.

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

Основным объектом манипуляции в HTTP является ресурс, на который указывает [[URI]] (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере [[файл]]ы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и [[Код ответа#Взаимодействие с веб-сервером (HTTP)|ответе]] способ представления одного и того же ресурса по различным параметрам: [[Формат данных|формату]], [[Набор символов|кодировке]], языку и т. д. (в частности, для этого используется [[Заголовки HTTP|HTTP-заголовок]]). Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться [[Двоичные данные|двоичными данными]], хотя данный протокол является текстовым.

HTTP — протокол [[Модель OSI|прикладного уровня]]; аналогичными ему являются [[File Transfer Protocol|FTP]] и [[SMTP]]. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные [[URI]]. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «[[HTTP cookie|куки]]» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить [[IP-адрес]]а и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

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

При доступе к данным по FTP или по файловым протоколам тип файла (точнее, тип содержащихся в нём данных) определяется по расширению имени файла, что не всегда удобно. HTTP перед тем, как передать сами данные, передаёт заголовок «Content-Type: тип/подтип», позволяющий клиенту однозначно определить, каким образом обрабатывать присланные данные. Это особенно важно при работе с [[CGI]]-скриптами, когда расширение имени файла указывает не на тип присылаемых клиенту данных, а на необходимость запуска данного файла на сервере и отправки клиенту результатов работы программы, записанной в этом файле (при этом один и тот же файл в зависимости от аргументов запроса и своих собственных соображений может порождать ответы разных типов — в простейшем случае картинки в разных форматах).

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

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

== Программное обеспечение ==
Всё программное обеспечение для работы с протоколом HTTP разделяется на три большие категории:
* Серверы как основные поставщики услуг хранения и обработки информации (обработка запросов);
* Клиенты — конечные потребители услуг сервера (отправка запроса);
* Прокси (посредники) для выполнения транспортных служб.
Для отличия конечных серверов от прокси в официальной документации используется термин «исходный сервер» ({{lang-en|origin server}}). Один и тот же программный продукт может одновременно выполнять функции клиента, сервера или посредника в зависимости от поставленных задач. В спецификациях протокола HTTP подробно описывается поведение для каждой из этих ролей.

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

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

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

=== Исходные серверы ===
Основные реализации: [[Apache HTTP Server|Apache]], [[Internet Information Services]] (IIS), [[nginx]], {{нп5|LiteSpeed Web Server|||LiteSpeed Web Server}} (LSWS), [[Google Web Server]], [[lighttpd]].

=== Прокси-серверы ===
Основные реализации: [[Squid]], [[UserGate]], [[Multiproxy]], [[Naviscope]], [[nginx]].

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

# Первая строка HTTP-сообщения определяет тип сообщения и называется:
#* {{lang-en|Request Line}} — «Строка запроса» — в запросах клиента
#* {{lang-en|Status Line}} — «Строка статуса» — в ответах сервера
# Заголовки ({{lang-en|Headers}}) — характеризуют тело сообщения, параметры передачи и прочие сведения.
# Тело сообщения ({{lang-en|Message Body}}) — непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

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

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

=== Стартовая строка ===
Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:
: <code>Метод URI</code> — для версии протокола 0.9;
: <code>Метод URI HTTP/Версия</code> — для остальных версий.

Здесь:
* Метод ({{lang-en|Method}}) — тип запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод <code>GET</code>, список методов для версии 1.1 представлен ниже.
* [[URI]] определяет путь к запрашиваемому документу.
* Версия ({{lang-en|Version}}) — пара разделённых точкой [[Арабские цифры|цифр]]. Например: <code>1.0</code>.
Чтобы запросить страницу данной статьи, клиент должен передать:
<syntaxhighlight lang="http">
GET /wiki/HTTP HTTP/1.1   ← Request Line (обязательна)
Host: ru.wikipedia.org    ← Заголовок
<пустая строка>           ← Конец заголовков
</syntaxhighlight>

Строка статуса ответа сервера ({{lang-en|Status Line}}) имеет следующий формат: <code>HTTP/Версия КодСостояния Пояснение</code>, где:
* версия — пара разделённых точкой цифр, как в запросе;
* код состояния ({{lang-en|Status Code}}) — три цифры. По [[Код ответа#Взаимодействие с веб-сервером (HTTP)|коду состояния]] определяется дальнейшее содержимое сообщения и поведение клиента;
* пояснение ({{lang-en|Reason Phrase}}) — текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

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

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

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

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

==== OPTIONS ====
Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок <code>[[Список заголовков HTTP#Allow|Allow]]</code> со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.

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

Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку — «<code>*</code>». Запросы «<code>OPTIONS * HTTP/1.1</code>» могут также применяться для проверки работоспособности сервера (аналогично «[[пинг]]ованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не [[Веб-кэш|кэшируется]].

==== GET ====
Используется для запроса содержимого указанного ресурса. С помощью метода <code>GET</code> можно также начать какой-либо процесс. В этом случае в тело ответного сообщения следует включить информацию о ходе выполнения процесса.

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «<code>?</code>»:<br><code>GET /path/resource?param1=value1&param2=value2 HTTP/1.1</code>

Согласно стандарту HTTP, запросы типа <code>GET</code> считаются [[Идемпотентность|идемпотентными]]<!-- да, ссылка на disambig, но что делать если статьи нет и перспектива сомнительна? --Incnis Mrsi --><ref name="http-spec-methods">{{cite web
 |url         = http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
 |title       = HTTP/1.1: Method Definitions
 |lang        = en
 |archive-url  = https://www.webcitation.org/68e5RnSBE?url=http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
 |archive-date = 2012-06-23
 |url-status     = dead
}}</ref>

Кроме обычного метода <code>GET</code>, различают ещё
* [[HTTP#Условные GET|Условный <code>GET</code>]] — содержит заголовки <code>If-Modified-Since</code>, <code>If-Match</code>, <code>If-Range</code> и подобные;
* [[HTTP#Частичные GET|Частичный <code>GET</code>]] — содержит в запросе <code>Range</code>.
Порядок выполнения подобных запросов определён стандартами отдельно.

==== HEAD ====
Аналогичен методу <code>GET</code>, за исключением того, что в ответе сервера отсутствует тело. Запрос <code>HEAD</code> обычно применяется для извлечения [[Метаданные|метаданных]], проверки наличия ресурса ([[валидация]] URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении [[Метаданные|метаданных]] ресурса с соответствующей информацией в кэше — копия ресурса помечается как устаревшая.

==== POST ====
{{основная статья | POST (HTTP)}}
Применяется для передачи пользовательских данных заданному ресурсу. Например, в [[блог]]ах посетители обычно могут вводить свои комментарии к записям в HTML-форму, после чего они передаются серверу методом [[POST (HTTP)|POST]] и он помещает их на страницу. При этом передаваемые данные (в примере с блогами — текст комментария) включаются в тело запроса. Аналогично с помощью метода <code>POST</code> обычно загружаются файлы на сервер.

В отличие от метода <code>GET</code>, метод <code>POST</code> не считается идемпотентным<ref name="http-spec-methods" />, то есть многократное повторение одних и тех же запросов <code>POST</code> может возвращать разные результаты (например, после каждой отправки комментария будет появляться очередная копия этого комментария).

При результате выполнения <code>200</code> (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ <code>201</code> (Created) с указанием [[URI]] нового ресурса в заголовке <code>Location</code>.

Сообщение ответа сервера на выполнение метода <code>POST</code> не кэшируется.

==== PUT ====
Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существует ресурса, то сервер создаёт его и возвращает статус <code>201</code> (Created). Если же ресурс был изменён, то сервер возвращает <code>200</code> (Ok) или <code>204</code> (No Content). Сервер не должен игнорировать некорректные заголовки <code>Content-*</code>, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или недопустим при текущих условиях, то необходимо вернуть код ошибки <code>501</code> (Not Implemented).

Фундаментальное различие методов <code>POST</code> и <code>PUT</code> заключается в понимании предназначений URI ресурсов. Метод <code>POST</code> предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя <code>PUT</code>, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод <code>PUT</code> не кэшируются.

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

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

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

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

=== Коды состояния ===
{{основная статья|Список кодов состояния HTTP}}
Код состояния является частью первой строки ответа сервера. Он представляет собой целое число из трёх цифр<ref name="3digits">См. первое предложение раздела «[[rfc:2068#section-6.1.1|6.1.1 Status Code and Reason Phrase]]» в <nowiki>RFC 2068</nowiki>. На [[rfc:2068#page-40|стр. 40]] есть также объявление в формате расширенной [[Форма Бэкуса — Наура|БНФ]]-формы ({{не переведено 3|Augmented Backus–Naur Form|Augmented BNF|en}}) «<code>extension-code = 3DIGIT</code>» для кодов расширений.</ref>. Первая цифра указывает на класс состояния. За [[Код ответа#Взаимодействие с веб-сервером (HTTP)|кодом ответа]] обычно следует отделённая пробелом поясняющая фраза на английском языке, которая разъясняет человеку причину именно такого ответа. Примеры:

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

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

В настоящее время выделено пять классов кодов состояния
{| class="wikitable"
!Код
!Класс
!Назначение
|-
|[[Список кодов состояния HTTP#1xx|<code>1xx</code>]]
|[[Список кодов состояния HTTP#1xx|Информационный]]

(англ. '''informational''')
|Информирование о процессе передачи.

В HTTP/1.0 — сообщения с такими кодами должны игнорироваться.

В HTTP/1.1 — клиент должен быть готов принять этот класс сообщений как обычный ответ, но ничего отправлять серверу не нужно.

Сами сообщения от сервера содержат только стартовую строку ответа и, возможно, несколько полей заголовка. [[Прокси-сервер]]ы подобные сообщения должны отправлять дальше от сервера к клиенту.
|-
|[[Список кодов состояния HTTP#2xx|<code>2xx</code>]]
|[[Список кодов состояния HTTP#2xx|Успех]]

(англ. '''Success''')
|Информирование о случаях успешного принятия и обработки запроса клиента. В зависимости от статуса, сервер может ещё передать заголовки и тело сообщения.
|-
|[[Список кодов состояния HTTP#3xx|<code>3xx</code>]]
|[[Список кодов состояния HTTP#3xx|Перенаправление]]

(англ. '''Redirection''')
|Сообщает клиенту, что для успешного выполнения операции необходимо сделать другой запрос (как правило по другому URI). Из данного класса пять кодов <code>[[Список кодов состояния HTTP#301|301]]</code>, <code>[[Список кодов состояния HTTP#302|302]]</code>, <code>[[Список кодов состояния HTTP#303|303]]</code>, <code>[[Список кодов состояния HTTP#305|305]]</code> и <code>[[Список кодов состояния HTTP#307|307]]</code> относятся непосредственно к перенаправлениям (редирект). Адрес, по которому клиенту следует произвести запрос, сервер указывает в заголовке <code>Location</code>. При этом допускается использование фрагментов в целевом URI.
|-
|[[Список кодов состояния HTTP#4xx|<code>4xx</code>]]
|[[Список кодов состояния HTTP#4xx|Ошибка клиента]]

(англ. '''Client Error''')
|Запрос клиента содержит ошибку. При использовании всех методов, кроме <code>HEAD</code>, сервер должен вернуть в теле сообщения гипертекстовое пояснение для пользователя.
|-
|[[Список кодов состояния HTTP#5xx|<code>5xx</code>]]
|[[Список кодов состояния HTTP#5xx|Ошибка сервера]]

(англ. '''Server Error''')
|Операция не выполнена по вине сервера. Для всех ситуаций, кроме использования метода <code>HEAD</code>, сервер должен включать в тело сообщения объяснение, которое клиент отобразит пользователю.
|}

=== Заголовки ===
{{основная статья|Заголовки HTTP|Список заголовков HTTP}}
Заголовки HTTP ({{lang-en|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

В примере выше каждая строка представляет собой один заголовок. При этом то, что находится до двоеточия, называется именем ({{lang-en|name}}), а что после него — значением ({{lang-en|value}}).

Все заголовки разделяются на четыре основных группы:
# [[Список заголовков HTTP#Основные заголовки|General Headers]] («Общие заголовки») — могут включаться в любое сообщение клиента и сервера.
# [[Список заголовков HTTP#Заголовки запроса|Request Headers]] («Заголовки запроса») — используются только в запросах клиента.
# [[Список заголовков HTTP#Заголовки ответа|Response Headers]] («Заголовки ответа») — только для ответов от сервера.
# [[Список заголовков HTTP#Заголовки сущности|Entity Headers]] («Заголовки сущности») — сопровождают каждую сущность сообщения.

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

Все необходимые для функционирования HTTP заголовки описаны в основных [[RFC]]. Если не хватает существующих, то можно вводить свои. Традиционно к именам таких дополнительных заголовков добавляют префикс «<code>X-</code>» для избежания конфликта имён с возможно существующими. Например, как в заголовках <code>X-Powered-By</code> или <code>X-Cache</code>. Некоторые разработчики используют свои индивидуальные префиксы. Примерами таких заголовков могут служить <code>Ms-Echo-Request</code> и <code>Ms-Echo-Reply</code>, введённые корпорацией Microsoft для расширения [[WebDAV]].

=== Тело сообщения ===
Тело HTTP-сообщения (<code>message-body</code>), если оно присутствует, используется для передачи тела объекта, связанного с запросом или ответом. Тело сообщения отличается от тела объекта (<code>entity-body</code>) только в том случае, когда применяется кодирование передачи, что указывается полем заголовка <code>Transfer-Encoding</code>.

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

Поле <code>Transfer-Encoding</code> должно использоваться для указания любого кодирования передачи, применённого приложением в целях гарантирования безопасной и правильной передачи сообщения. Поле <code>Transfer-Encoding</code> — это свойство сообщения, а не объекта, и, таким образом, может быть добавлено или удалено любым приложением в цепочке запросов/ответов.

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

Присутствие тела сообщения в запросе отмечается добавлением к заголовкам запроса поля заголовка <code>Content-Length</code> или <code>Transfer-Encoding</code>. Тело сообщения может быть добавлено в запрос, только когда метод запроса допускает тело объекта.

Включается или не включается тело сообщения в сообщение ответа — зависит как от метода запроса, так и от кода состояния ответа. Все ответы на запрос с методом <code>HEAD</code> не должны включать тело сообщения, даже если присутствуют поля заголовка объекта (<code>entity-header</code>), заставляющие поверить в присутствие объекта. Никакие ответы с кодами состояния <code>1xx</code> (Информационные), <code>204</code> (Нет содержимого, No Content), и <code>304</code> (Не модифицирован, Not Modified) не должны содержать тела сообщения. Все другие ответы содержат тело сообщения, даже если оно имеет нулевую длину.

== Примеры диалогов HTTP ==
{{Скрытый
| Заголовок     = Обычный GET-запрос
| Фон_заголовка = {{Цвет|Accent75}}
| Содержание    = Запрос клиента:
 [[#GET|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]])''

Аналогично выглядит ответ <code>203</code>. Что существенно — непосредственно запрашиваемые данные отделены от HTTP-заголовков с помощью [[Возврат каретки|CR]], [[Перевод строки|LF]], CR, LF.
}}

{{Скрытый
| Заголовок     = Перенаправления
| Фон_заголовка = {{Цвет|Accent75}}
| Содержание    =
Предположим, что у вымышленной компании '''«Example Corp.»''' есть основной сайт по адресу '''<nowiki>«http://example.com»</nowiki>''' и домен-псевдоним '''«example.org»'''. Клиент посылает запрос страницы '''«О компании»''' на вторичный домен (часть заголовков опущена):

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

Так как домен '''«example.org»''' не является основным и компания не собирается в будущем его использовать в других целях, их сервер вернёт код для постоянного перенаправления, указав в заголовке <code>Location</code> целевой URL:
 HTTP/1.x [[Список кодов состояния HTTP#301|301 Moved Permanently]]
 Location: <nowiki>http://example.com/about.html#contacts</nowiki>
 Date: Thu, 19 Feb 2009 11:08:01 GMT
 Server: Apache/2.2.4
 Content-Type: text/html; charset=windows-1251
 Content-Length: 110
 <span style="color: #888">''(пустая строка)''</span>
 <nowiki><html><body><a href="http://example.com/about.html#contacts">Click here</a></body></html></nowiki>

В заголовке <code>Location</code> можно указывать фрагменты как в данном примере. Браузер не указал фрагмент в запросе, так как его интересует весь документ. Но он автоматически прокрутит страницу до фрагмента «contacts», как только загрузит её. В тело ответа также был помещён короткий HTML-документ со ссылкой, с помощью которой посетитель попадёт на целевую страницу, если браузер не перейдёт на неё автоматически. Заголовок <code>Content-Type</code> содержит характеристики именно этого HTML-пояснения, а не документа, который находится по целевому URI.

Допустим, эта же компания '''«Example Corp.»''' имеет несколько региональных представительств по всему миру. И для каждого представительства у них есть сайт с соответствующим [[Национальный домен верхнего уровня|ccTLD]]. Запрос главной страницы основного сайта '''«example.com»''' может выглядеть так:
 [[#GET|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

Сервер принял во внимание заголовок <code>Accept-Language</code> и сформировал ответ со временным перенаправлением на российский сервер '''«example.ru»''', указав его адрес в заголовке <code>Location</code>:

 HTTP/1.x [[Список кодов состояния HTTP#302|302 Found]]
 Location: <nowiki>http://example.ru/</nowiki>
 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
 <span style="color: #888">''(пустая строка)''</span>
 <nowiki><html><body><a href="http://example.ru">Example Corp.</a></body></html></nowiki>

Обратите внимание на заголовок <code>Cache-Control</code>: значение '''«private»''' сообщает остальным серверам (в первую очередь прокси) что ответ может кэшироваться только на стороне клиента. В противном случае не исключено, что следующие посетители из других стран будут переходить всё время не в своё представительство.

Для перенаправления также используются коды ответа <code>[[Список кодов состояния HTTP#303|303]]</code> (See Other) и <code>[[Список кодов состояния HTTP#307|307]]</code> (Temporary Redirect).
}}

{{Скрытый
| Заголовок     = Докачка и фрагментарное скачивание
| Фон_заголовка = {{Цвет|Accent75}}
| Содержание    =
Допустим, вымышленная организация предлагает скачать с сайта видео прошедшей конференции по адресу: '''«<nowiki>http://example.org/conf-2009.avi»</nowiki>''' — объёмом примерно 160 [[Мегабайт|МБ]]. Рассмотрим, как происходит докачивание этого файла в случае сбоя и как [[менеджер закачек]] организовал бы [[Многопоточность (аппаратное обеспечение)|многопоточную]] загрузку нескольких фрагментов.

В обоих случаях клиенты произведут свой первый запрос наподобие этого:
 GET /conf-2009.avi HTTP/1.0
 Host: example.org
 Accept: */*
 User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98)
 Referer: <nowiki>http://example.org/</nowiki>

Заголовок <code>Referer</code> указывает, что файл был запрошен с главной страницы сайта. Менеджеры закачек обычно тоже его указывают, чтобы эмулировать переход со страницы сайта. Без него сервер может ответить <code>[[Список кодов состояния HTTP#403|403]]</code> (Access Forbidden), если не допускаются запросы с других сайтов. В нашем случае сервер вернул успешный ответ:

 HTTP/1.1 [[Список кодов состояния HTTP#200|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
 <span style="color: #888">''(пустая строка)''</span>
 <span style="color: #555">''(двоичное содержимое всего файла)''</span>

Заголовок <code>Accept-Ranges</code> информирует клиента о том, что он может запрашивать у сервера фрагменты, указывая их смещения от начала файла в байтах. Если этот заголовок отсутствует, то клиент может предупредить пользователя, что докачать файл, скорее всего, не удастся.

Исходя из значения заголовка <code>Content-Length</code>, менеджер закачек поделит весь объём на равные фрагменты и запросит их по отдельности, организовав несколько потоков. Если сервер не укажет размер, то клиенту параллельное скачивание реализовать не удастся, но при этом он сможет докачивать файл, пока сервер не ответит [[Список кодов состояния HTTP#416|<code>416</code>]] (Requested Range Not Satisfiable).

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

 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: <nowiki>http://example.org/</nowiki>

Сервер не обязан помнить, какие и от кого запросы были до этого, и поэтому клиент снова вставил заголовок <code>Referer</code>, как будто это его самый первый запрос. Указанное значение заголовка <code>Range</code> говорит серверу: «Выдай содержимое от 88080384-го байта до самого конца». В связи с этим сервер вернёт ответ:

 HTTP/1.1 [[Список кодов состояния HTTP#206|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
 <span style="color: #888">''(пустая строка)''</span>
 <span style="color: #555">''(двоичное содержимое от 84-го мегабайта)''</span>

Заголовок <code>Accept-Ranges</code> здесь уже не обязателен, так как клиент уже знает об этой возможности сервера. О том, что передаётся фрагмент, клиент узнаёт по коду <code>[[Список кодов состояния HTTP#206|206]]</code> (Partial Content). В заголовке <code>Content-Range</code> содержится информация о данном фрагменте: номера начального и конечного байта, а после слэша — суммарный объём всего файла в байтах. Обратите внимание на заголовок <code>Content-Length</code> — в нём указывается размер тела сообщения, то есть передаваемого фрагмента. Если сервер вернёт несколько фрагментов, то <code>Content-Length</code> будет содержать их суммарный объём.

Теперь вернёмся к менеджеру закачек. Зная суммарный объём файла '''«conf-2009.avi»''', программа поделила его на 10 равных секций.

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

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

Ответ сервера в этом случае будет следующим (часть заголовков опущена — см. полный пример выше):

 HTTP/1.1 [[Список кодов состояния HTTP#206|206 Partial Content]]
 Accept-Ranges: bytes
 Content-Range: bytes 64397516-80496894/160993792
 Content-Length: 16099379
 <span style="color: #888">''(пустая строка)''</span>
 <span style="color: #555">''(двоичное содержимое 4-й части)''</span>

Если подобный запрос отправить серверу, который не поддерживает фрагменты, то он вернёт стандартный ответ <code>[[Список кодов состояния HTTP#200|200]]</code> (OK) как было показано в самом начале, но без заголовка <code>Accept-Ranges</code>.
}}

: ''См. также [[HTTP#Частичные GET|частичные GET]], [[Заголовки HTTP#Байтовые диапазоны|байтовые диапазоны]], [[Список кодов состояния HTTP#206|ответ 206]], [[Список кодов состояния HTTP#416|ответ 416]].''

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

=== Частичные GET ===
HTTP позволяет запросить не сразу всё содержимое ресурса, а только указанный фрагмент. Такие запросы называются частичные <code>GET</code>; возможность их выполнения необязательна (но желательна) для серверов. Частичные <code>GET</code> в основном используются для [[Менеджер закачек|докачки файлов]] и быстрого параллельного скачивания в нескольких потоках. Некоторые программы скачивают заголовок архива, выводят пользователю внутреннюю структуру, а потом уже запрашивают фрагменты с указанными элементами архива.

Для получения фрагмента клиент посылает серверу запрос с заголовком <code>Range</code>, указывая в нём необходимые [[Заголовки HTTP#Байтовые диапазоны|байтовые диапазоны]]. Если сервер не понимает частичные запросы (игнорирует заголовок <code>Range</code>), то он вернёт всё содержимое со статусом <code>[[HTTP 200|200]]</code>, как и при обычном <code>GET</code>. В случае успешного выполнения сервер возвращает вместо кода <code>200</code> ответ со статусом <code>206</code> (Partial Content), включая в ответ заголовок <code>Content-Range</code>. Сами фрагменты могут быть переданы двумя способами:

* в ответе помещается заголовок <code>Content-Range</code> с указанием байтовых диапазонов. В соответствии с ними фрагменты последовательно помещаются в основное тело. При этом <code>Content-Length</code> должен соответствовать суммарному объёму всего тела;
* сервер указывает медиатип <code>multipart/byteranges</code> для основного содержимого и передаёт фрагменты, указывая соответствующий <code>Content-Range</code> для каждого элемента (см. также «Множественное содержимое»{{переход|Множественное содержимое}}).

=== Условные GET ===
Метод <code>GET</code> изменяется на «условный <code>GET</code>», если сообщение запроса включает в себя поле заголовка <code>If-Modified-Since</code>. В ответ на «условный <code>GET</code>» тело запрашиваемого ресурса передаётся, только если он изменялся после даты, указанной в заголовке <code>If-Modified-Since</code>. Алгоритм определения этого включает в себя следующие случаи:
* если статус ответа на запрос будет отличаться от «200 OK» или дата, указанная в поле заголовка «If-Modified-Since», некорректна, ответ будет идентичен ответу на обычный запрос GET;
* если после указанной даты ресурс изменялся, ответ будет также идентичен ответу на обычный запрос GET;
* если ресурс не изменялся после указанной даты, сервер вернет статус «304 Not Modified».
Использование метода «условный GET» направлено на разгрузку сети, так как он позволяет не передавать по сети избыточную информацию.

=== Согласование содержимого ===
Согласование содержимого ({{lang-en|Content Negotiation}}) — механизм автоматического определения необходимого ресурса при наличии нескольких разнотипных версий документа. Субъектами согласования могут быть не только ресурсы сервера, но и возвращаемые страницы с сообщениями об ошибках ([[HTTP 403|403]], [[HTTP 404|404]] и т. п.).

Различают два основных типа согласований:
* управляемое сервером ({{lang-en|server-driven}});
* управляемое клиентом ({{lang-en|agent-driven}}).

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

В основной спецификации по протоколу (RFC 2616) также выделяется так называемое прозрачное согласование ({{lang-en|transparent negotiation}}) как предпочтительный вариант комбинирования обоих типов. Последний механизм не следует путать с независимой технологией Transparent Content Negotiation (TCN, «Прозрачное согласование содержимого», см. RFC 2295), которая не является частью протокола HTTP, но может использоваться с ним. У обоих существенное различие в принципе работы и самом значении слова «прозрачное» (transparent). В спецификации по HTTP под прозрачностью подразумевается, что процесс не заметен для клиента и сервера, а в технологии TCN прозрачность означает доступность полного списка вариантов ресурса для всех участников процесса доставки данных.

==== Управляемое сервером ====
При наличии нескольких версий ресурса сервер может анализировать заголовки запроса клиента, чтобы выдать, по его мнению, наиболее подходящую. В основном анализируются заголовки <code>Accept</code>, <code>Accept-Charset</code>, <code>Accept-Encoding</code>, <code>Accept-Languages</code> и <code>[[User Agent|User-Agent]]</code>. Серверу желательно включать в ответ заголовок <code>Vary</code> с указанием параметров, по которым различается содержимое по запрашиваемому URI.

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

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

Управляемое сервером согласование имеет несколько недостатков:
* сервер только предполагает, какой вариант наиболее предпочтителен для конечного пользователя, но не может знать точно, что именно нужно в данный момент (например, версия на русском языке или английском);
* заголовков группы Accept передаётся много, а ресурсов с несколькими вариантами — мало. Из-за этого оборудование испытывает избыточную нагрузку;
* общему кэшу создаётся ограничение возможности выдавать один и тот же ответ на идентичные запросы от разных пользователей;
* передача заголовков Accept также может раскрывать некоторые сведения о его предпочтениях, таких как используемые языки, браузер, кодировка.

==== Управляемое клиентом ====
В данном случае тип содержимого определяется только на стороне клиента.
Для этого сервер возвращает в ответе с кодом состояния <code>300</code> (Multiple Choices) или <code>406</code> (Not Acceptable) список вариантов, среди которых пользователь выбирает подходящий.
Управляемое клиентом согласование хорошо, когда содержимое различается по самым частым параметрам (например, по языку и кодировке) и используется публичный кэш.

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

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

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

=== Множественное содержимое ===
{{основная статья|MIME}}
Протокол HTTP поддерживает передачу нескольких сущностей в пределах одного сообщения. Причём сущности могут передаваться не только в виде одноуровневой последовательности, но и в виде [[Иерархическая структура|иерархии]] с вложением элементов друг в друга. Для обозначения множественного содержимого используются медиатипы <code>multipart/*</code>. Работа с такими типами осуществляется по общим правилам, описанным в RFC 2046 (если иное не определено конкретным медиатипом). Если получателю не известно как работать с типом, то он обрабатывает его так же, как <code>multipart/mixed</code>.

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

Со стороны сервера сообщения со множественным содержимым могут посылаться в ответ на [[HTTP#Частичные GET|частичные <code>GET</code>]] при запросе нескольких фрагментов ресурса. В этом случае используется медиатип <code>multipart/byteranges</code>.

Со стороны клиента при отправке [[HTML]]-формы чаще всего пользуются методом <code>POST</code>. Типичный пример: страницы отправки [[Электронная почта|электронных писем]] со вложенными файлами. При отправке такого письма браузер формирует сообщение типа <code>multipart/form-data</code>, интегрируя в него как отдельные части, введённые пользователем, тему письма, адрес получателя, сам текст и вложенные файлы:

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

В примере в заголовках <code>Content-Disposition</code> параметр <code>name</code> соответствует атрибуту <code>name</code> в HTML-тегах <code>&lt;INPUT&gt;</code> и <code>&lt;TEXTAREA&gt;</code>. Параметр <code>filename</code> равен исходному имени файла на компьютере пользователя. Более подробная информация о формировании 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 год]]а<ref>Впервые спецификация HTTP/1.1 была опубликована в январе [[1997]] {{Inet-note-ref|type=rfc|id=2068|text=RFC 2068}}; в современной версии {{Inet-note-ref|type=rfc|id=2616|text=RFC 2616}} исправлены опечатки, местами улучшены терминология и оформление. Также разъяснено допустимое поведение клиента (браузера), сервера и [[прокси-сервер]]ов в некоторых сомнительных ситуациях. То есть версия 1.1 появилась всё-таки в 1997 году.</ref>. Новым в этой версии был режим «постоянного соединения»: [[TCP]]-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени [[хост]]а, к которому он обращается, что сделало возможной более простую организацию [[Виртуальный хостинг|виртуального хостинга]].

; HTTP/2 : {{main|HTTP/2}}
: 11 февраля [[2015 год]]а опубликованы финальные версии черновика следующей версии протокола. В отличие от предыдущих версий, протокол HTTP/2 является [[Бинарный код|бинарным]]. Среди ключевых особенностей: [[мультиплексирование]] запросов, расстановка приоритетов для запросов, сжатие заголовков, загрузка нескольких элементов параллельно посредством одного [[TCP]]-соединения, поддержка проактивных [[Push-уведомления|push-уведомлений]] со стороны сервера<ref>{{Cite web |url=https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 |title=HTTP/2 Draft |access-date=2015-02-25 |archive-date=2015-02-20 |archive-url=https://web.archive.org/web/20150220174227/https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 |url-status=live }}</ref>.

; HTTP/3
: {{main|HTTP/3}}
: HTTP/3 — предлагаемый последователь HTTP/2<ref>{{cite web
|lang=en
|url=https://tools.ietf.org/html/draft-ietf-quic-http-22
|title=Hypertext Transfer Protocol Version 3 (HTTP/3)
|author=
|first=Mike
|last=Bishop
|website=tools.ietf.org
|date=2019-07-09
|access-date=2019-08-16
|archive-date=2019-08-31
|archive-url=https://web.archive.org/web/20190831231502/https://tools.ietf.org/html/draft-ietf-quic-http-22
|url-status=live
}}</ref><ref>{{Cite news|url=https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/|title=HTTP-over-QUIC to be renamed HTTP/3 {{!}} ZDNet|last=Cimpanu|first=Catalin|work=ZDNet|lang=en|archive-date=2018-11-13|archive-url=https://web.archive.org/web/20181113020115/https://www.zdnet.com/article/http-over-quic-to-be-renamed-http3/|access-date=2020-08-10}}</ref>, который уже используется в Веб на основе [[UDP]] вместо [[TCP]] в качестве транспортного протокола. Как и HTTP/2, он не объявляет устаревшими предыдущие основные версии протокола. Поддержка HTTP/3 была добавлена в [[Cloudflare]] и [[Google Chrome]] в сентябре 2019 года<ref>{{cite web|url=https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/|title=Cloudflare, Google Chrome, and Firefox add HTTP/3 support|website=ZDNet|date=2019-09-26|access-date=2019-09-27|first=Catalin|last=Cimpanu|archive-date=2019-09-26|archive-url=https://web.archive.org/web/20190926131659/https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/|url-status=live}}</ref><ref>{{Cite web|url=https://blog.cloudflare.com/http3-the-past-present-and-future/|title=HTTP/3: the past, the present, and the future|date=2019-09-26|website=The Cloudflare Blog|lang=en|access-date=2019-10-30|archive-date=2019-09-26|archive-url=https://web.archive.org/web/20190926131655/https://blog.cloudflare.com/http3-the-past-present-and-future/|url-status=live}}</ref> и может быть включена в стабильных версиях Chrome и Firefox<ref>{{cite web |url=https://community.cloudflare.com/t/firefox-nightly-supports-http-3/127778 |title=Firefox Nightly supports HTTP 3 - General - Cloudflare Community |date=2019-11-19 |access-date=2020-01-23 |archive-date=2020-06-06 |archive-url=https://web.archive.org/web/20200606233655/https://community.cloudflare.com/t/firefox-nightly-supports-http-3/127778 |url-status=live }}</ref>.

== См. также ==
{{wiktionary|HTTP}}
* [[Список кодов состояния HTTP]]
* [[Заголовки HTTP]] ([[Список заголовков HTTP|список]]):
** [[HTTP referer|Referer]]
** [[User Agent|User-Agent]]
* [[HTTP-Cookie|Cookie]]
* [[Дайджест-аутентификация]]
* [[HTTP/2]]
* [[HTTPS]]

== Примечания ==
{{примечания|2}}

== Ссылки ==
{{Commons-inline|Category:HTTP|HTTP}}
* RFC 1945 — HTTP/1.0 (Май 1996), включает версию 0.9
* RFC 2616 — HTTP/1.1 (Июнь 1999); см. также в виде [https://web.archive.org/web/20060216231757/http://ftp.isi.edu/in-notes/rfc2616.ps PostScript] и [http://tools.ietf.org/pdf/rfc2616 PDF];
* [https://tools.ietf.org/html/draft-ietf-httpbis-http2-17 httpbis-http2-17] — HTTP/2 (11 февраля 2015) Окончательная спецификация
* [https://web.archive.org/web/20180126185718/https://bagder.gitbooks.io/http2-explained/content/ru/ «Разъяснение http/2» Даниэль Штенберг]{{ref|ru}}
* [http://www.rfc-editor.org/errata_search.php?rfc=2616 Найденные опечатки в спецификации HTTP/1.1]
* [www.lib.ru/WEBMASTER/rfc2068/ Перевод спецификации HTTP/1.1]
* [http://www.w3.org/Protocols/HTTP/AsImplemented.html Первоначальный HTTP 0.9] Тима Бернерса-Ли (написан и издан в 1991 году)
* [http://www.w3.org/Protocols/HTTP/HTTP2.html Ранняя версия исходного черновика] версии 1.0 1992 года Тима Бернерса-Ли
* [http://www.eventhelix.com/RealtimeMantra/Networking/http_sequence_diagram.pdf Пример последовательности HTTP-обмена] {{Wayback|url=http://www.eventhelix.com/RealtimeMantra/Networking/http_sequence_diagram.pdf |date=20120805165406 }} между браузером и сервером
* [http://apachedev.ru/2006/03/12/the-apache-modeling-project-glava-2-chast-1/ Функционирование HTTP-сервера]

{{URI scheme}}
{{IPstack}}
{{Семантическая паутина}}
{{HTTP}}

{{спам-ссылки|1=
* www.lib.ru/WEBMASTER/rfc2068/
}}

[[Категория:Протокол HTTP|*]]
[[Категория:Открытые форматы]]
[[Категория:Интернет-протоколы]]
[[Категория:Стандарты W3C]]
[[Категория:Протоколы прикладного уровня]]