HTTP

HTTP

Международный стандарт	RFC   1945 HTTP/1.0 RFC   9110 Семантика HTTP RFC   9111 HTTP-кэширование RFC   9112 HTTP/1.1 RFC   9113 HTTP/2 RFC   7541 HTTP/2: сжатие заголовка HPACK RFC   8164 HTTP/2: Оппортунистическая безопасность для HTTP/2. RFC   8336 HTTP/2: кадр ORIGIN HTTP/2. RFC   8441 HTTP/2: загрузка WebSockets с помощью HTTP/2 RFC   9114 HTTP/3 RFC   9204 HTTP/3: QPACK: сжатие полей
Разработано	первоначально ЦЕРН ; IETF , W3C
Представлено	1991 год ( 1991 )
Веб-сайт	https://httpwg.org/specs/

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

Разработка HTTP была инициирована Тимом Бернерсом-Ли в ЦЕРНе в 1989 году и обобщена в простом документе, описывающем поведение клиента и сервера с использованием первой версии HTTP, получившей название 0.9. Эта версия впоследствии была разработана и в конечном итоге стала общедоступной версией 1.0.

Разработка первых HTTP- запросов на комментарии (RFC) началась несколько лет спустя в результате скоординированных усилий Инженерной группы Интернета (IETF) и Консорциума Всемирной паутины (W3C), а позже работа перешла в IETF.

HTTP/1 был доработан и полностью документирован (как версия 1.0) в 1996 году. Он развивался (как версия 1.1) в 1997 году, а затем его спецификации обновлялись в 1999, 2014 и 2022 годах.

Его безопасный вариант под названием HTTPS используется более чем 85% веб-сайтов. HTTP/2 , опубликованный в 2015 году, обеспечивает более эффективное выражение семантики HTTP «по сети». По состоянию на январь 2024 г. его используют 36% веб-сайтов и поддерживается почти всеми веб-браузерами (более 98% пользователей). Он также поддерживается основными веб-серверами через Transport Layer Security (TLS) с использованием расширения согласования протокола прикладного уровня (ALPN). где TLS 1.2 или новее. требуется

HTTP/3 , преемник HTTP/2, был опубликован в 2022 году. По состоянию на февраль 2024 г. сейчас он используется на 29% веб-сайтов и поддерживается большинством веб-браузеров, т.е. (по крайней мере частично) поддерживается 97% пользователей. HTTP/3 использует QUIC вместо TCP в качестве базового транспортного протокола. Как и HTTP/2, он не устаревает предыдущие основные версии протокола. Поддержка HTTP/3 сначала была добавлена ​​в Cloudflare и Google Chrome . а также включен в Firefox . HTTP/3 имеет меньшую задержку для реальных веб-страниц, если он включен на сервере, и загружается быстрее, чем HTTP/2, в некоторых случаях более чем в три раза быстрее, чем HTTP/1.1 (который до сих пор обычно только включен).

Технический обзор

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

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

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

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

HTTP — это протокол прикладного уровня, разработанный в рамках набора протоколов Интернета . Его определение предполагает базовый и надежный протокол транспортного уровня . В последней версии HTTP/3 протокол управления передачей (TCP) больше не используется, но более старые версии по-прежнему используются чаще и чаще всего используют TCP. Они также были адаптированы для использования ненадежных протоколов, таких как протокол пользовательских дейтаграмм (UDP), на котором HTTP/3 также (косвенно) всегда основывается, например, в HTTPU и простом протоколе обнаружения служб (SSDP).

Ресурсы HTTP идентифицируются и располагаются в сети с помощью унифицированных указателей ресурсов (URL) с использованием схем унифицированных идентификаторов ресурсов (URI) http и https . Как определено в RFC   3986 , URI кодируются как гиперссылки в документах HTML , чтобы сформировать взаимосвязанные гипертекстовые документы.

отдельное TCP- соединение с одним и тем же сервером. В HTTP/1.0 для каждого запроса ресурса устанавливается

Вместо этого в HTTP/1.1 TCP-соединение можно повторно использовать для выполнения нескольких запросов ресурсов (например, HTML-страниц, фреймов, изображений, сценариев , таблиц стилей и т. д.).

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

HTTP/2 — это версия предыдущего HTTP/1.1, позволяющая поддерживать ту же модель клиент-сервер и те же методы протокола, но с перечислением этих различий по порядку:

• использовать сжатое двоичное представление метаданных (HTTP-заголовки) вместо текстового, чтобы заголовки занимали гораздо меньше места;
• использовать одно соединение TCP/IP (обычно зашифрованное ) для каждого домена сервера, к которому осуществляется доступ, вместо 2–8 соединений TCP/IP;
• использовать один или несколько двунаправленных потоков для каждого TCP/IP-соединения, в которых HTTP-запросы и ответы разбиваются и передаются небольшими пакетами, чтобы практически решить проблему HOLB ( блокировки заголовка ).
• добавить возможность push-уведомления, позволяющую серверному приложению отправлять данные клиентам всякий раз, когда доступны новые данные (не заставляя клиентов периодически запрашивать новые данные на сервер с помощью методов опроса ).

Таким образом, связь HTTP/2 имеет гораздо меньшую задержку и, в большинстве случаев, даже более высокую скорость, чем связь HTTP/1.1.

HTTP/3 — это версия предыдущего HTTP/2, позволяющая использовать транспортные протоколы QUIC + UDP вместо TCP. До этой версии использовались соединения TCP/IP; но теперь используется только уровень IP (на котором основан UDP, как и TCP). Это немного улучшает среднюю скорость связи и позволяет избежать случайной (очень редкой) проблемы перегрузки TCP-соединения , которая может временно блокировать или замедлять поток данных всех его потоков (еще одна форма « блокировки начала строки »).

История

Тим Бернерс-Ли

Термин «гипертекст» был придуман Тедом Нельсоном в 1965 году в рамках проекта «Занаду» , который, в свою очередь, был вдохновлен видением Ванневара Буша » для поиска и управления информацией на основе микрофильмов, 1930-х годов о системе « мемекс описанной в его эссе 1945 года « Как мы можем думать». ". Тиму Бернерсу-Ли и его команде в ЦЕРНе приписывают изобретение оригинального HTTP, а также HTML и связанной с ним технологии для веб-сервера и клиентского пользовательского интерфейса , называемого веб-браузером . Бернерс-Ли разработал HTTP, чтобы помочь в принятии другой своей идеи: проекта WorldWideWeb, который был впервые предложен в 1989 году и теперь известен как World Wide Web .

Первый веб-сервер был запущен в 1990 году. Используемый протокол имел только один метод, а именно GET, который запрашивал страницу с сервера. Ответом от сервера всегда была HTML-страница.

Сводка основных версий HTTP

Версия	Год введения	Текущий статус
HTTP/0.9	1991	Устаревший
HTTP/1.0	1996	Устаревший
HTTP/1.1	1997	Стандартный
HTTP/2	2015	Стандартный
HTTP/3	2022	Стандартный

HTTP/0.9

В 1991 году первая задокументированная официальная версия HTTP была написана в виде простого документа длиной менее 700 слов, и эта версия получила название HTTP/0.9, которая поддерживала только метод GET, позволяя клиентам получать только HTML-документы с сервера, но не поддерживает никакие другие форматы файлов или загрузку информации.

HTTP/1.0-черновик

С 1992 года был написан новый документ, описывающий развитие базового протокола к его следующей полной версии. Он поддерживал как простой метод запроса версии 0.9, так и полный запрос GET, включающий версию HTTP клиента. Это был первый из многих неофициальных проектов HTTP/1.0, предшествовавших окончательной работе над HTTP/1.0.

Рабочая группа W3C HTTP

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

Рабочая группа HTTP планировала пересмотреть и опубликовать новые версии протокола как HTTP/1.0 и HTTP/1.1 в течение 1995 года, но из-за множества изменений этот график продлился гораздо больше одного года.

Рабочая группа HTTP планировала также определить будущую версию HTTP под названием HTTP-NG (HTTP Next Generation), которая решила бы все оставшиеся проблемы предыдущих версий, связанные с производительностью, ответами с низкой задержкой и т. д., но эта работа началась только несколько лет спустя, но он так и не был завершен.

HTTP/1.0

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

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

HTTP/1.1

С начала 1996 года основные разработчики веб-браузеров и веб-серверов также начали реализовывать новые функции, указанные в черновиках спецификаций предстандарта HTTP/1.1. Принятие конечными пользователями новых версий браузеров и серверов произошло быстро. В марте 1996 года одна веб-хостинговая компания сообщила, что более 40% браузеров, используемых в Интернете, использовали новый заголовок HTTP/1.1 «Host» для включения виртуального хостинга , и что к июню 1996 года 65% всех браузеров, обращающихся к их серверам, были Совместимость с предварительным стандартом HTTP/1.1.

В январе 1997 года RFC   2068 был официально выпущен как спецификация HTTP/1.1.

В июне 1999 года Был выпущен RFC   2616 , включающий все улучшения и обновления, основанные на предыдущих (устаревших) спецификациях HTTP/1.1.

Рабочая группа W3C HTTP-NG

Возобновляя старый план предыдущей рабочей группы HTTP 1995 года, в 1997 году была сформирована рабочая группа HTTP-NG для разработки нового протокола HTTP под названием HTTP-NG (HTTP New Generation). Было сделано несколько предложений/проектов для нового протокола, позволяющего использовать мультиплексирование HTTP-транзакций внутри одного соединения TCP/IP, но в 1999 году группа прекратила свою деятельность, передав технические проблемы в IETF.

Рабочая группа IETF HTTP возобновила работу

В 2007 году рабочая группа IETF HTTP (HTTP WG bis или HTTPbis) была перезапущена, во-первых, для пересмотра и уточнения предыдущих спецификаций HTTP/1.1, а во-вторых, для написания и уточнения будущих спецификаций HTTP/2 (названных httpbis).

SPDY: неофициальный протокол HTTP, разработанный Google.

В 2009 году частная компания Google объявила, что разработала и протестировала новый двоичный протокол HTTP под названием SPDY . Неявной целью было значительно ускорить веб-трафик (особенно между будущими веб-браузерами и их серверами).

Во многих тестах SPDY действительно был намного быстрее, чем HTTP/1.1, поэтому он был быстро принят Chromium , а затем и другими основными веб-браузерами.

Некоторые идеи о мультиплексировании потоков HTTP через одно соединение TCP/IP были взяты из различных источников, включая работу рабочей группы W3C HTTP-NG.

HTTP/2

В январе – марте 2012 года Рабочая группа HTTP (HTTPbis) объявила о необходимости сосредоточиться на новом протоколе HTTP/2 (завершая при этом пересмотр спецификаций HTTP/1.1), возможно, принимая во внимание идеи и работу, проделанную для SPDY.

После нескольких месяцев размышлений о том, что делать для разработки новой версии HTTP, было решено вывести ее из SPDY.

В мае 2015 года HTTP/2 был опубликован как RFC   7540 и быстро принят всеми веб-браузерами, уже поддерживающими SPDY, и медленнее — веб-серверами.

Обновления HTTP/1.1 2014 г.

В июне 2014 года рабочая группа HTTP выпустила обновленную спецификацию HTTP/1.1, состоящую из шести частей, устаревшую. RFC   2616 :

• RFC   7230 , HTTP/1.1: Синтаксис сообщений и маршрутизация
• RFC   7231 , HTTP/1.1: Семантика и контент
• RFC   7232 , HTTP/1.1: Условные запросы
• RFC   7233 , HTTP/1.1: запросы диапазона
• RFC   7234 , HTTP/1.1: Кэширование
• RFC   7235 , HTTP/1.1: Аутентификация

Прекращение поддержки HTTP/0.9

В Приложение-A RFC   7230 , HTTP/0.9 устарел для серверов, поддерживающих версию HTTP/1.1 (и выше):

Поскольку HTTP/0.9 не поддерживал поля заголовка в запросе, в нем не существует механизма поддержки виртуальных хостов на основе имени (выбор ресурса путем проверки поля заголовка Host). Любой сервер, реализующий виртуальные хосты на основе имен, должен отключить поддержку HTTP/0.9 . Большинство запросов, которые кажутся HTTP/0.9, на самом деле являются плохо построенными запросами HTTP/1.x, вызванными тем, что клиент не может правильно закодировать цель запроса.

С 2016 года многие менеджеры по продуктам и разработчики пользовательских агентов (браузеров и т. д.) и веб-серверов начали планировать постепенное прекращение поддержки протокола HTTP/0.9, главным образом по следующим причинам:

• настолько просто, что документ RFC никогда не был написан (есть только исходный документ);
• в нем нет HTTP-заголовков и многих других функций, которые в настоящее время необходимы из соображений минимальной безопасности;
• он не получил широкого распространения с 1999 по 2000 год (из-за HTTP/1.0 и HTTP/1.1) и обычно используется только некоторым очень старым сетевым оборудованием, например маршрутизаторами и т. д.

HTTP/3

В 2020 году были опубликованы первые проекты HTTP/3 , и его начали использовать основные веб-браузеры и веб-серверы.

6 июня 2022 года IETF стандартизировал HTTP/3 как РФК   9114 .

Обновления и рефакторинг в 2022 году

В июне 2022 года была опубликована серия RFC, в которой многие предыдущие документы признаны устаревшими и внесены несколько незначительных изменений и рефакторинг описания семантики HTTP в отдельный документ.

• RFC   9110 , Семантика HTTP
• RFC   9111 , HTTP-кэширование
• RFC   9112 , HTTP/1.1
• RFC   9113 , HTTP/2
• RFC   9114 , HTTP/3 (см. также раздел выше)
• RFC   9204 , QPACK: сжатие полей для HTTP/3
• RFC   9218 , Расширяемая схема приоритезации для HTTP

HTTP-обмен данными

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

Сообщения запроса и ответа через соединения

Обмен данными осуществляется через последовательность сообщений запрос-ответ , которыми обмениваются транспортные соединения сеансового уровня . HTTP-клиент сначала пытается подключиться к серверу, устанавливая соединение (реальное или виртуальное). Сервер HTTP(S), прослушивающий этот порт, принимает соединение, а затем ожидает сообщения запроса от клиента. Клиент отправляет сообщение HTTP-запроса. После получения запроса сервер отправляет ответное сообщение HTTP, которое включает в себя заголовок(и) плюс тело, если оно необходимо. Тело этого ответного сообщения обычно представляет собой запрошенный ресурс, хотя также может быть возвращено сообщение об ошибке или другая информация. В любой момент (по многим причинам) клиент или сервер могут закрыть соединение. Закрытие соединения обычно объявляется заранее с использованием одного или нескольких заголовков HTTP в последнем сообщении запроса/ответа, отправленном на сервер или клиент.

Постоянные соединения

Основная статья: постоянное соединение HTTP

В HTTP/0.9 соединение TCP/IP всегда закрывается после отправки ответа сервера, поэтому оно никогда не бывает постоянным.

В HTTP/1.0 , как указано в RFC 1945, соединение TCP/IP всегда должно закрываться сервером после отправки ответа.

В HTTP/1.1 был официально введен механизм поддержания активности, позволяющий повторно использовать соединение для более чем одного запроса/ответа. запроса Такие постоянные соединения заметно сокращают задержку , поскольку клиенту не нужно повторно согласовывать соединение TCP 3-Way-Handshake после отправки первого запроса. Еще одним положительным побочным эффектом является то, что в целом соединение со временем становится быстрее благодаря механизму медленного запуска TCP .

В HTTP/1.1 также добавлена ​​конвейерная обработка HTTP , чтобы еще больше сократить время задержки при использовании постоянных соединений, позволяя клиентам отправлять несколько запросов перед ожиданием каждого ответа. Эта оптимизация никогда не считалась действительно безопасной, потому что несколько веб-серверов и множество прокси-серверов , специально прозрачных прокси-серверов, размещенных в Интернете / интранетах между клиентами и серверами, не обрабатывали конвейерные запросы должным образом (они обслуживали только первый запрос, отбрасывая остальные, они закрывались). соединение, потому что они увидели больше данных после первого запроса или некоторые прокси даже вернули ответы не по порядку и т. д.). Из-за этого только запросы HEAD и некоторые запросы GET (т. е. ограниченные реальными запросами файлов и, следовательно, URL-адресами без строки запроса, используемой в качестве команды и т. д.) могут передаваться по конвейеру в безопасном и идемпотентном режиме. После многих лет борьбы с проблемами, возникшими при включении конвейерной обработки, эта функция была сначала отключена, а затем удалена из большинства браузеров, также из-за объявленного внедрения HTTP/2.

HTTP/2 расширил использование постоянных соединений за счет мультиплексирования множества одновременных запросов/ответов через одно соединение TCP/IP.

HTTP/3 использует соединения не TCP/IP, а QUIC + UDP (см. также: технический обзор ).

Оптимизация поиска контента

HTTP/0.9

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

HTTP/1.0

В HTTP/1.0 добавлены заголовки для управления ресурсами, кэшированными клиентом, чтобы разрешить условные запросы GET; на практике сервер должен возвращать все содержимое запрошенного ресурса только в том случае, если время его последнего изменения не известно клиенту или если оно изменилось с момента последнего полного ответа на запрос GET. Один из этих заголовков, «Content-Encoding», был добавлен для указания того, было ли возвращенное содержимое ресурса сжато или нет .

Если общая длина содержимого ресурса заранее не была известна (т. е. поскольку оно было сгенерировано динамически и т. д.), то заголовок "Content-Length: number" не присутствовал в заголовках HTTP, и клиент предполагал, что когда сервер закрыл соединение, контент был отправлен полностью. Этот механизм не мог отличить успешно завершенную передачу ресурса от прерванной (из-за ошибки сервера/сети или чего-то еще).

HTTP/1.1

HTTP/1.1 представлен:

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

HTTP/2, HTTP/3

И HTTP/2, и HTTP/3 сохранили вышеупомянутые функции HTTP/1.1.

HTTP-аутентификация

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

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

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

Области аутентификации

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

Сеанс HTTP-приложения

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

Некоторым веб-приложениям необходимо управлять сеансами пользователей, поэтому они реализуют состояния или сеансы на стороне сервера , используя, например, файлы cookie HTTP. или скрытые переменные в веб-формах .

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

Сообщения запроса HTTP/1.1

Сообщения запроса отправляются клиентом на целевой сервер.

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

Клиент отправляет сообщения запроса , которые состоят из: серверу

• строка запроса , состоящая из метода запроса с учетом регистра, пробела , запрошенного URL-адреса, другого пробела, версии протокола, возврата каретки и перевода строки , например:

GET /images/logo.png HTTP/1.1

• ноль или более полей заголовка запроса (по крайней мере, 1 или более заголовков в случае HTTP/1.1), каждое из которых состоит из имени поля без учета регистра, двоеточия, необязательных начальных пробелов , значения поля, необязательных конечных пробелов и заканчивается символом возврат каретки и перевод строки, например:

Host: www.example.com
Accept-Language: en

• пустая строка, состоящая из возврата каретки и перевода строки;
• необязательное тело сообщения .

В протоколе HTTP/1.1 все поля заголовка, кроме Host: hostname являются необязательными.

Строка запроса, содержащая только имя пути, принимается серверами для обеспечения совместимости с HTTP-клиентами до появления спецификации HTTP/1.0 в РФК   1945 .

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

Запрос HTTP/1.1, сделанный с помощью telnet. Сообщение запроса , раздел заголовка ответа и текст ответа выделяются.

HTTP определяет методы (иногда называемые глаголами , но нигде в спецификации он не упоминается ) , чтобы указать желаемое действие, которое должно быть выполнено над идентифицированным ресурсом. То, что представляет этот ресурс, будь то уже существующие данные или данные, генерируемые динамически, зависит от реализации сервера. Часто ресурс соответствует файлу или результату исполняемого файла, находящегося на сервере. Спецификация HTTP/1.0 определены методы GET, HEAD и POST, а также перечислены методы PUT, DELETE, LINK и UNLINK в дополнительных методах. Однако спецификация HTTP/1.1 формально определены и добавлены пять новых методов: PUT, DELETE, CONNECT, OPTIONS и TRACE. Любой клиент может использовать любой метод, а сервер можно настроить для поддержки любой комбинации методов. Если метод неизвестен промежуточному звену, он будет рассматриваться как небезопасный и неидемпотентный метод. Количество определяемых методов не ограничено, что позволяет указывать будущие методы, не нарушая существующую инфраструктуру. Например, WebDAV определил семь новых методов и В RFC   5789 указан метод PATCH .

Имена методов чувствительны к регистру. В этом отличие от имен полей заголовка HTTP, которые не чувствительны к регистру.

ПОЛУЧАТЬ

Метод GET запрашивает, чтобы целевой ресурс передал представление о своем состоянии. Запросы GET должны только извлекать данные и не должны иметь никакого другого эффекта. (Это также верно и для некоторых других методов HTTP.) Для получения ресурсов без внесения изменений GET предпочтительнее POST, поскольку к ним можно обратиться через URL-адрес . Это позволяет создавать закладки и делиться ими, а ответы GET можно кэшировать , что может сэкономить полосу пропускания. W3C При опубликовал руководящие принципы по этому разграничению, в которых говорится: « проектировании веб-приложений следует учитывать вышеуказанные принципы, а также соответствующие ограничения». См. безопасные методы ниже.

ГОЛОВА

Метод HEAD запрашивает, чтобы целевой ресурс передавал представление своего состояния, как и в случае запроса GET, но без данных представления, заключенных в теле ответа. Это полезно для получения метаданных представления в заголовке ответа без необходимости передавать все представление. Использование включает проверку доступности страницы по коду состояния и быстрое определение размера файла ( Content-Length).

ПОЧТА

Метод POST запрашивает, чтобы целевой ресурс обработал представление, включенное в запрос, в соответствии с семантикой целевого ресурса. Например, он используется для публикации сообщения на интернет-форуме , подписки на список рассылки или совершения транзакции онлайн-покупки .

ПОМЕЩАТЬ

Метод PUT запрашивает, чтобы целевой ресурс создал или обновил свое состояние до состояния, определенного представлением, включенным в запрос. Отличие от POST заключается в том, что клиент указывает целевое расположение на сервере.

УДАЛИТЬ

Метод DELETE запрашивает, чтобы целевой ресурс удалил свое состояние.

СОЕДИНЯТЬ

Метод CONNECT запрашивает, чтобы посредник установил туннель TCP/IP к исходному серверу, указанному в цели запроса. Он часто используется для защиты соединений через один или несколько HTTP-прокси с помощью TLS . См. метод HTTP CONNECT .

ПАРАМЕТРЫ

Метод OPTIONS запрашивает, чтобы целевой ресурс перенес поддерживаемые им методы HTTP. Это можно использовать для проверки работоспособности веб-сервера, запрашивая «*» вместо конкретного ресурса.

СЛЕД

Метод TRACE запрашивает, чтобы целевой ресурс передал полученный запрос в теле ответа. Таким образом, клиент может увидеть, какие (если были) изменения или дополнения были внесены посредниками.

ПЛАСТЫРЬ

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

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

Свойства методов запроса

Метод запроса	RFC	Запрос имеет тело полезной нагрузки	Ответ имеет тело полезной нагрузки.	Безопасный	Идемпотент	Кэшируемый
ПОЛУЧАТЬ	РФК   9110	Необязательный	Да	Да	Да	Да
ГОЛОВА	РФК   9110	Необязательный	Нет	Да	Да	Да
ПОЧТА	РФК   9110	Да	Да	Нет	Нет	Да
ПОМЕЩАТЬ	РФК   9110	Да	Да	Нет	Да	Нет
УДАЛИТЬ	РФК   9110	Необязательный	Да	Нет	Да	Нет
СОЕДИНЯТЬ	РФК   9110	Необязательный	Да	Нет	Нет	Нет
ПАРАМЕТРЫ	РФК   9110	Необязательный	Да	Да	Да	Нет
СЛЕД	РФК   9110	Нет	Да	Да	Да	Нет
ПЛАСТЫРЬ	RFC   5789	Да	Да	Нет	Нет	Нет

Безопасные методы

Метод запроса безопасен , если запрос с использованием этого метода не оказывает ожидаемого воздействия на сервер. Методы GET, HEAD, OPTIONS и TRACE определены как безопасные. Другими словами, безопасные методы предназначены только для чтения . Однако они не исключают побочных эффектов , таких как добавление информации о запросе в файл журнала или списание средств с рекламного аккаунта , поскольку они по определению не запрашиваются клиентом.

Напротив, методы POST, PUT, DELETE, CONNECT и PATCH небезопасны. Они могут изменять состояние сервера или иметь другие последствия, например отправку электронного письма . Поэтому такие методы обычно не используются соответствующими веб-роботами или веб-сканерами; некоторые, кто не соответствует, склонны делать запросы без учета контекста или последствий.

Несмотря на предписанную безопасность GET-запросов, на практике их обработка сервером никак технически не ограничена. Небрежное или намеренно неправильное программирование может привести к тому, что запросы GET вызовут нетривиальные изменения на сервере. Это не рекомендуется из-за проблем, которые могут возникнуть, когда веб-кэширование , поисковые системы и другие автоматические агенты вносят непреднамеренные изменения на сервере. Например, веб-сайт может разрешить удаление ресурса через URL-адрес, такой как https://example.com/article/1234/delete , который, если его произвольно извлечь, даже с использованием GET, просто удалит статью. На правильно закодированном веб-сайте для этого действия потребуется метод DELETE или POST, который не будут выполнять незлонамеренные боты.

Одним из примеров того, как это происходило на практике, был период недолговечной бета-версии Google Web Accelerator , которая предварительно загружала произвольные URL-адреса на странице, которую просматривал пользователь, что приводило к автоматическому массовому изменению или удалению записей . Бета -версия была приостановлена ​​всего через несколько недель после ее первого выпуска из-за широкой критики.

Идемпотентные методы

См. Также: Идемпотентность § Значение информатики

Метод запроса является идемпотентным , если несколько идентичных запросов с этим методом имеют тот же эффект, что и один такой запрос. Методы PUT и DELETE, а также безопасные методы определены как идемпотентные. Безопасные методы тривиально идемпотентны, поскольку они не должны оказывать никакого влияния на сервер; Между тем методы PUT и DELETE идемпотентны, поскольку последовательные идентичные запросы будут игнорироваться. Например, веб-сайт может настроить конечную точку PUT для изменения записанного адреса электронной почты пользователя. Если эта конечная точка настроена правильно, любые запросы на изменение адреса электронной почты пользователя на уже записанный адрес электронной почты (например, дублирующие запросы после успешного запроса) не будут иметь никакого эффекта. Аналогично, запрос на УДАЛЕНИЕ определенного пользователя не будет иметь никакого эффекта, если этот пользователь уже был удален.

Напротив, методы POST, CONNECT и PATCH не обязательно являются идемпотентными, и поэтому отправка идентичного запроса POST несколько раз может дополнительно изменить состояние сервера или иметь дополнительные последствия, такие как отправка нескольких электронных писем . В некоторых случаях это желаемый эффект, но в других случаях он может возникнуть случайно. Например, пользователь может случайно отправить несколько запросов POST, повторно нажав кнопку, если ему не будет предоставлена ​​четкая информация о том, что первый щелчок обрабатывается. Хотя веб-браузеры могут отображать диалоговые окна с предупреждениями , чтобы предупредить пользователей в некоторых случаях, когда перезагрузка страницы может повторно отправить запрос POST, обычно веб-приложение должно обрабатывать случаи, когда запрос POST не следует отправлять более одного раза.

Обратите внимание, что вопрос о том, является ли метод идемпотентным, не определяется протоколом или веб-сервером. Вполне возможно написать веб-приложение, в котором (например) вставка в базу данных или другое неидемпотентное действие запускается GET или другим запросом. Однако нарушение рекомендаций может привести к нежелательным последствиям, если пользовательский агент предполагает, что повторение одного и того же запроса безопасно, хотя это не так.

Кэшируемые методы

См. также: Веб-кэш.

Метод запроса является кэшируемым , если ответы на запросы с помощью этого метода могут быть сохранены для повторного использования в будущем. Методы GET, HEAD и POST определены как кэшируемые.

Напротив, методы PUT, DELETE, CONNECT, OPTIONS, TRACE и PATCH не кэшируются.

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

См. также: Список полей HTTP-заголовка § Поля запроса.

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

Ответные сообщения HTTP/1.1

Ответное сообщение отправляется сервером клиенту в качестве ответа на его предыдущее сообщение запроса.

Синтаксис ответа

Сервер отправляет ответные сообщения , которые состоят из: клиенту

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

  HTTP/1.1 200 OK
  

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

  Content-Type: text/html
  

• пустая строка, состоящая из возврата каретки и перевода строки;
• необязательное тело сообщения .

Коды статуса ответа

См. также: Список кодов состояния HTTP.

В HTTP/1.0 и последующих версиях первая строка ответа HTTP называется строкой состояния и включает в себя числовой код состояния (например, « 404 ») и текстовую фразу причины (например, «Не найден»). Код состояния ответа представляет собой трехзначный целочисленный код, представляющий результат попытки сервера понять и удовлетворить соответствующий запрос клиента. То, как клиент обрабатывает ответ, зависит в первую очередь от кода состояния и, во вторую очередь, от других полей заголовка ответа. Клиенты могут не понимать все зарегистрированные коды состояния, но они должны понимать свой класс (задаваемый первой цифрой кода состояния) и рассматривать нераспознанный код состояния как эквивалент кода состояния x00 этого класса.

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

Первая цифра кода состояния определяет его класс:

1XX (информационный)

Запрос получен, обработка продолжается.

2XX (успешный)

Запрос был успешно получен, понят и принят.

3XX (перенаправление)

Для выполнения запроса необходимо предпринять дальнейшие действия.

4XX (ошибка клиента)

Запрос содержит неправильный синтаксис или не может быть выполнен.

5XX (ошибка сервера)

Серверу не удалось выполнить очевидно действительный запрос.

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

См. также: Список полей заголовка HTTP § Поля ответа.

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

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

Пример HTTP/1.1 транзакции запроса/ответа

Ниже приведен пример HTTP-транзакции между клиентом HTTP/1.1 и сервером HTTP/1.1, работающим на www.example.com , порт 80.

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

GET / HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive

Клиентский запрос (состоящий в данном случае из строки запроса и нескольких заголовков, которые можно свести только к "Host: hostname" заголовок) следует пустая строка, так что запрос заканчивается двойным концом строки, каждый из которых представляет собой возврат каретки, за которым следует перевод строки . "Host: hostname" Значение заголовка различает различные DNS- имена, использующие один IP-адрес на основе имен , что позволяет осуществлять виртуальный хостинг . Хотя это необязательно в HTTP/1.0, оно является обязательным в HTTP/1.1. (Кошка «/» (косая черта) обычно означает файл /index.html , если он есть.)

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

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <p>Hello World, this is a very simple HTML document.</p>
  </body>
</html>

Поле заголовка ETag (тег объекта) используется для определения того , идентична ли кэшированная версия запрошенного ресурса текущей версии ресурса на сервере. "Content-Type" определяет тип Интернет-носителя данных, передаваемых HTTP-сообщением, а "Content-Length" указывает его длину в байтах. HTTP/1.1 Веб-сервер публикует свою способность отвечать на запросы определенных диапазонов байтов документа, устанавливая поле "Accept-Ranges: bytes". Это полезно, если клиенту нужно иметь только определенные порции. ресурса, отправленного сервером, что называется обслуживанием байтов . Когда "Connection: close" отправляется, это означает, что веб-сервер закроет TCP- соединение сразу после окончания передачи этого ответа.

Большинство строк заголовка не являются обязательными, но некоторые являются обязательными. Когда заголовок "Content-Length: number" отсутствует в ответе с телом объекта, то это следует считать ошибкой в ​​HTTP/1.0, но это может не быть ошибкой в ​​HTTP/1.1, если заголовок "Transfer-Encoding: chunked" присутствует. При кодировании передачи фрагментов используется размер фрагмента, равный 0, для обозначения конца содержимого. В некоторых старых реализациях HTTP/1.0 заголовок отсутствовал. "Content-Length" когда длина объекта тела не была известна в начале ответа, и поэтому передача данных клиенту продолжалась до тех пор, пока сервер не закрыл сокет.

А "Content-Encoding: gzip" может использоваться для информирования клиента о том, что часть тела передаваемых данных сжимается алгоритмом gzip.

Зашифрованные соединения

Самый популярный способ установки зашифрованного HTTP-соединения — HTTPS . Также существуют два других метода установки зашифрованного HTTP-соединения: протокол безопасной передачи гипертекста и использование заголовка обновления HTTP/1.1 для указания обновления до TLS. Однако поддержка этих двух браузеров практически отсутствует.

Подобные протоколы

• Протокол Gopher — это протокол доставки контента, который был заменен HTTP в начале 1990-х годов.
• Протокол SPDY — альтернатива HTTP, разработанная в Google , замененная HTTP/2 .
• Протокол Gemini — это протокол, основанный на Gopher, который требует функций, связанных с конфиденциальностью.

См. также

• Межпланетная файловая система – может заменить HTTP.
• Сравнение протоколов передачи файлов
• Протокол ограниченного приложения — семантически аналогичный протокол HTTP, но использующий UDP или UDP-подобные сообщения, предназначенные для устройств с ограниченными возможностями обработки; повторно использует HTTP и другие концепции Интернета, такие как тип интернет-медиа и веб-ссылки (RFC 5988).
• Согласование содержания
• Дайджест-аутентификация доступа
• HTTP-сжатие
• HTTP/2 — разработан рабочей группой IETF по протоколу передачи гипертекста (httpbis).
• Список полей заголовка HTTP
• Список кодов состояния HTTP
• Представительская государственная передача (REST)
• Вариант объекта
• Протокол беспроводных приложений
• Веб-кеш
• Вебсокет

Внешние ссылки

• Официальный сайт
• Рабочая группа IETF HTTP на GitHub
• «История изменений для HTTP» . W3.org . Проверено 1 августа 2010 г. Подробная техническая история HTTP.
• «Проблемы проектирования HTTP» . W3.org . Проверено 1 августа 2010 г. Проблемы проектирования Бернерса-Ли, когда он разрабатывал протокол.