Протокол передачи гипертекста

Протокол передачи гипертекста

Международный стандарт	RFC  1945 HTTP/1.0 (1996) RFC  2068 HTTP/1.1 (1997 г.) RFC  2616 HTTP/1.1 (1999 г.) RFC  7230 HTTP/1.1: Синтаксис и маршрутизация сообщений (2014 г.) RFC  7231 HTTP/1.1: семантика и контент (2014 г.) RFC  7232 HTTP/1.1: условные запросы (2014 г.) RFC  7233 HTTP/1.1: запросы диапазона (2014 г.) RFC  7234 HTTP/1.1: Кэширование (2014 г.) RFC  7235 HTTP/1.1: Аутентификация (2014 г.) RFC  7540 HTTP/2 (2015 г.) RFC  7541 HTTP/2: сжатие заголовков HPACK (2015 г.) RFC  8164 HTTP/2: Уступающая безопасность для HTTP/2 (2017 г.) RFC  8336 HTTP/2: кадр ORIGIN HTTP/2 (2018 г.) RFC  8441 HTTP/2: Начальная загрузка веб-сокетов с помощью HTTP/2 (2018 г.) RFC  8740 HTTP/2: использование TLS 1.3 с HTTP/2 (2020 г.)
Разработано	изначально ЦЕРН ; IETF , W3C
Представлен	1991 ; 31 год назад ( 1991 )

Протокол передачи гипертекста ( HTTP ) — это протокол прикладного уровня в модели набора интернет-протоколов для распределенных, совместных информационных систем гипермедиа . ^[2] HTTP является основой передачи данных для World Wide Web , где гипертекстовые документы включают гиперссылки на другие ресурсы, к которым пользователь может легко получить доступ, например, щелкнув мышью или коснувшись экрана в веб-браузере.

Разработка HTTP была инициирована Тимом Бернерсом-Ли в CERN в 1989 году и обобщена в простом документе, описывающем поведение клиента и сервера с использованием первой версии протокола HTTP, которая называлась 0.9. ^[3]

Эта первая версия протокола HTTP вскоре превратилась в более сложную версию, которая стала первым наброском будущей версии 1.0. ^[4]

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

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

Его безопасный вариант под названием HTTPS используется более чем на 76% веб-сайтов. ^[7]

HTTP/2 является более эффективным выражением семантики HTTP «на линии» и был опубликован в 2015 году; его используют более 45% веб-сайтов; ^[8] теперь он поддерживается почти всеми веб-браузерами (96% пользователей) ^[9] и основными веб-серверами через Transport Layer Security (TLS) с использованием расширения Application-Layer Protocol Negotiation (ALPN) ^[10] , где TLS 1.2 или требуется новее. ^{[11] [12]}

HTTP/3 является предполагаемым преемником HTTP/2; ^{[13] [14]} используется более чем на 20% веб-сайтов; ^[15] теперь он поддерживается многими веб-браузерами (73% пользователей). ^[16] HTTP/3 использует QUIC вместо TCP в качестве базового транспортного протокола. Как и HTTP/2, он не отменяет предыдущие основные версии протокола. Поддержка HTTP/3 сначала была добавлена ​​в Cloudflare и Google Chrome , ^{[17] [18],} а также включена в Firefox . ^[19]

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

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

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

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

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

HTTP — это протокол прикладного уровня , разработанный в рамках набора интернет-протоколов . Его определение предполагает базовый и надежный протокол транспортного уровня ^[20] , поэтому обычно используется протокол управления передачей (TCP). Однако HTTP можно адаптировать для использования ненадежных протоколов, таких как протокол пользовательских дейтаграмм (UDP), например, в HTTPU и простой протокол обнаружения служб (SSDP).

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

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

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

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

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

• использовать сжатое бинарное представление метаданных (HTTP-заголовки) вместо текстового, чтобы заголовки занимали гораздо меньше места;
• использовать одно соединение TCP/IP (обычно зашифрованное ) для каждого доступного домена сервера вместо 2..8 соединений TCP/IP;
• использовать один или несколько двунаправленных потоков для каждого TCP/IP-соединения, в котором HTTP-запросы и ответы разбиваются и передаются небольшими пакетами, что почти решает проблему HOLB ( блокировка начала строки ; ПРИМЕЧАНИЕ. на практике эти потоки используются как несколько Подсоединения TCP/IP для мультиплексирования одновременных запросов/ответов, что значительно сокращает количество реальных соединений TCP/IP на стороне сервера с 2..8 на клиента до 1 и позволяет обслуживать гораздо больше клиентов одновременно);
• чтобы добавить возможность принудительной отправки, чтобы серверное приложение могло отправлять данные клиентам всякий раз, когда новые данные доступны (без принуждения клиентов периодически запрашивать новые данные на сервер с помощью методов опроса ). ^[25]

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

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

История

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

Первый веб-сервер был запущен в 1990 году . ^{[26] [27]} Используемый протокол имел только один метод, а именно GET, который запрашивал страницу с сервера. ^[28] Ответ сервера всегда представлял собой HTML-страницу. ^[3]

HTTP/0.9
В 1991 году первая задокументированная официальная версия HTTP была написана в виде простого документа и эта версия называлась HTTP/0.9. ^[3]

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

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

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

Рабочая группа по 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. ^[32]

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

В январе 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. ^[34]

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

Окончательное обновление HTTP/1.1
В июне 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: аутентификация

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

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

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

HTTP/2
В январе-марте 2012 года Рабочая группа HTTP (HTTPbis) объявила о необходимости начать работу над новым протоколом HTTP/2 (завершая пересмотр спецификаций HTTP/1.1), возможно, принимая во внимание идеи и работу, проделанную для SPDY. . ^{[38] [39]}

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

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

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

Поскольку HTTP/0.9 не поддерживает поля заголовков в запросе, существует

нет механизма для поддержки виртуальных хостов на основе имени (выбор

ресурса путем проверки поля заголовка Host). Любой сервер, который

реализует виртуальные хосты на основе имен, следует отключить поддержку

HTTP/0.9. Большинство запросов, которые выглядят как HTTP/0.9, на самом деле являются

плохо сконструированные запросы HTTP/1.x, вызванные тем, что клиент не смог

правильно закодировать цель запроса.

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

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

ПРИМЕЧАНИЕ: в 2021 году поддержка HTTP/0.9 официально не объявлена ​​полностью устаревшей и все еще присутствует (даже если она обычно отключена) на многих веб-серверах и браузерах (только для ответов сервера), поэтому неясно, сколько времени займет это отклонение. возможно, это будет сначала выполнено в пользовательских агентах (браузерах и т. д.), а затем в веб-серверах.

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

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

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

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

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

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

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

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

В HTTP/1.0 , как указано в RFC 1945, TCP/IP- соединение всегда должно быть закрыто сервером после отправки ответа. ПРИМЕЧАНИЕ: с конца 1996 года некоторые разработчики популярных браузеров и серверов HTTP/1.0 (особенно те, которые планировали также поддержку HTTP/1.1) начали развертывать (как неофициальное расширение) своего рода механизм поддержки активности (используя новые заголовки HTTP), чтобы поддерживать соединение TCP/IP открытым не только для пары запрос/ответ и, таким образом, ускорить обмен несколькими запросами/ответами. ^[32]

В 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 добавлены заголовки для управления ресурсами, кэшированными клиентом, чтобы разрешить условные запросы GET ; на практике сервер должен возвращать все содержимое запрошенного ресурса только в том случае, если время его последнего изменения неизвестно клиенту или если оно изменилось с момента последнего полного ответа на запрос GET.

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

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

В HTTP/1.1 добавлены новые заголовки для лучшего управления условным извлечением кэшированных ресурсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это краткое введение в сообщения запросов HTTP/1.1 (они имеют ту же — более или менее — семантику, что и в HTTP/1.0).

ПРИМЕЧАНИЕ. HTTP/2 и HTTP/3 по-разному представляют методы и заголовки HTTP.

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

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

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

GET /images/logo.png HTTP/1.1

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

Host: www.example.comAccept-Language: en

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

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

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

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

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

Имена методов чувствительны к регистру. ^{[51] [52]} Это отличается от имен полей заголовков HTTP, которые нечувствительны к регистру. ^[53]

ПОЛУЧИТЬ

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

ГОЛОВА

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

ПОЧТА

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

СТАВИТЬ

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

УДАЛИТЬ

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

СОЕДИНЯТЬ

Метод CONNECT требует, чтобы посредник установил туннель TCP/IP к серверу-источнику, указанному целью запроса. Он часто используется для защиты соединений через один или несколько HTTP-прокси с TLS . ^{[57] [58] [59]} См . метод HTTP CONNECT .

ОПЦИИ

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

СЛЕД

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

ПЛАСТЫРЬ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это краткое введение в ответные сообщения HTTP/1.1 (они имеют ту же — более или менее — семантику, что и в HTTP/1.0).

ПРИМЕЧАНИЕ. HTTP/2 и HTTP/3 по-разному представляют статус и заголовки HTTP.

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

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

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

HTTP/1.1 200 OK

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

Content-Type: text/html

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

Коды состояния ответа

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ПРИМЕЧАНИЕ. HTTP/1.0 содержит те же сообщения, за исключением нескольких отсутствующих заголовков.

ПРИМЕЧАНИЕ. HTTP/2 и HTTP/3 используют один и тот же механизм запроса/ответа, но с разными представлениями заголовков HTTP.

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

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 Соединение :  keep-alive

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

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

HTTP / 1.1  200  OK Дата :  понедельник, 23 мая 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 " Принять-диапазоны :  байты Соединение :  закрыть< html >  < head >  < title > Пример страницы </ title >  </ head >  < body >  < p > Hello World, это очень простой HTML-документ. </ p >  </ body > </ html >

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

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

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

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

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

Похожие протоколы

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

Смотрите также

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

использованная литература

внешняя ссылка

Викискладе есть медиафайлы, связанные с протоколом передачи гипертекста .

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