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 Created403 Access allowed only for registered users507 Insufficient Storage

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

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

Заголовки HTTP (англ. HTTP Headers) — это строки в HTTP-сообщении, содержащие разделённую двоеточием пару параметр-значение. Формат заголовков соответствует общему формату заголовков текстовых сетевых сообщений ARPA (см.RFC 822). Заголовки должны отделяться от тела сообщения хотя бы одной пустой строкой.

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

Server: Apache/2.2.11 (Win32) PHP/5.3.0Last-Modified: Sat, 16 Jan 2010 21:16:42 GMTContent-Type: text/plain; charset=windows-1251Content-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.1Host: ru.wikipedia.orgUser-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5Accept: text/htmlConnection: close(пустая строка)

HTTP/1.1 200 OKDate: Wed, 11 Feb 2009 11:20:59 GMTServer: ApacheX-Powered-By: PHP/5.2.4-2ubuntu5wm1Last-Modified: Wed, 11 Feb 2009 11:20:59 GMTContent-Language: ruContent-Type: text/html; charset=utf-8Content-Length: 1234Connection: close(пустая строка)(запрошенная страница вHTML)

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

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

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

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

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

HTTP/1.1200 OKDate: Thu, 19 Feb 2009 12:27:04 GMTServer: Apache/2.2.3Last-Modified: Wed, 18 Jun 2003 16:05:58 GMTETag: "56d-9989200-1132c580"Content-Type: video/x-msvideoContent-Length: 160993792Accept-Ranges: bytesConnection: close(пустая строка)(двоичное содержимое всего файла)

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

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

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

HTTP/1.1206 Partial ContentAccept-Ranges: bytesContent-Range: bytes 64397516-80496894/160993792Content-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.1Host: mail.example.comReferer: http://mail.example.com/send-message.htmlUser-Agent: BrowserForDummies/4.67bContent-Type: multipart/form-data; boundary="Asrf456BGe4h"Content-Length:(суммарный объём, включая дочерние заголовки)Connection: keep-aliveKeep-Alive: 300(пустая строка)(отсутствующая преамбула)--Asrf456BGe4hContent-Disposition: form-data; name="DestAddress"(пустая строка)brutal-vasya@example.com—Asrf456BGe4hContent-Disposition: form-data; name="MessageTitle"(пустая строка)Я негодую—Asrf456BGe4hContent-Disposition: form-data; name="MessageText"(пустая строка)Привет, Василий! Твой ручной лев, которого ты оставилу меня на прошлой неделе, разодрал весь мой диван.Пожалуйста, забери его скорее!Во вложении две фотки с последствиями.--Asrf456BGe4hContent-Disposition: form-data; name="AttachedFile1"; filename="horror-photo-1.jpg"Content-Type: image/jpeg(пустая строка)(двоичное содержимое первой фотографии)--Asrf456BGe4hContent-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
• Заголовки 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-сервера

В статьене хватаетссылок на источники (см.рекомендации по поиску). Информация должна бытьпроверяема, иначе она может быть удалена. Вы можетеотредактировать статью, добавив ссылки наавторитетные источники в видесносок.(27 июля 2013)

Некоторые внешние ссылки в этой статье ведут на сайты, занесённые вспам-лист. Эти сайты могут нарушать авторские права, быть признанынеавторитетными источниками или по другим причинам быть запрещены в Википедии. Редакторам следует заменить такие ссылкиссылками на соответствующие правилам сайты или библиографическими ссылками на печатные источники либо удалить их (возможно, вместе с подтверждаемым ими содержимым). Список проблемных ссылок www.lib.ru/WEBMASTER/rfc2068/

• Появились в 1990 году
• Семантическая паутина
• Протокол HTTP
• Открытые форматы
• Интернет-протоколы
• Стандарты W3C
• Протоколы прикладного уровня

• Страницы, использующие расширение JsonConfig
• Википедия:Cite web (заменить webcitation-архив: deadlink yes)
• Википедия:Cite web (не указан язык)
• Страницы, использующие волшебные ссылки RFC
• ПРО:ИТ:Статьи по алфавиту
• ПРО:ИТ:Последняя правка: в текущем году
• Статьи со ссылками на Викисловарь
• Википедия:Статьи без ссылок на источники с июля 2013 года
• Википедия:Статьи без источников (тип: сетевой протокол)
• Википедия:Статьи со спам-ссылками
• Википедия:Статьи с шаблонами недостатков по алфавиту