✖


Jump to content

HTTP

Страница защищена ожидающими изменениями
(Перенаправлено из протокола 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 год ; 33 года назад ( 1991 )
Веб-сайт https://httpwg.org/specs/
HTTP
Методы запроса
Поля заголовка
Коды статуса ответа
Методы безопасного контроля доступа
Уязвимости безопасности
Набор интернет-протоколов
Прикладной уровень
Транспортный уровень
Интернет-слой
Слой связи

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

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

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

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

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

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

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

[ редактировать ]

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

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

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

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

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

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

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

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

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

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

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

Таким образом, связь 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 году. [25] [26] Используемый протокол имел только один метод, а именно GET, который запрашивал страницу с сервера. [27] Ответом от сервера всегда была HTML-страница. [2]

Сводка основных версий 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-документы с сервера, но не поддерживает никакие другие форматы файлов или загрузку информации. [2]
HTTP/1.0-черновик
С 1992 года был написан новый документ, описывающий развитие базового протокола к его следующей полной версии. Он поддерживал как простой метод запроса версии 0.9, так и полный запрос GET, включающий версию HTTP клиента. Это был первый из многих неофициальных проектов HTTP/1.0, предшествовавших окончательной работе над HTTP/1.0. [3]
Рабочая группа W3C HTTP
После принятия решения о том, что необходимы новые функции протокола HTTP и что они должны быть полностью задокументированы в качестве официальных RFC , в начале 1995 года была создана Рабочая группа HTTP (HTTP WG, возглавляемая Дэйвом Рэггеттом ) с целью стандартизации и расширения протокола. с расширенными операциями, расширенными согласованиями, более богатой метаинформацией, связанной с протоколом безопасности, который стал более эффективным за счет добавления дополнительных методов и полей заголовка . [28] [29]
Рабочая группа HTTP планировала пересмотреть и опубликовать новые версии протокола как HTTP/1.0 и HTTP/1.1 в течение 1995 года, но из-за множества изменений этот график продлился гораздо больше одного года. [30]
Рабочая группа 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. [31]
HTTP/1.1
С начала 1996 года основные разработчики веб-браузеров и веб-серверов также начали реализовывать новые функции, указанные в черновиках спецификаций предстандарта HTTP/1.1. Принятие конечными пользователями новых версий браузеров и серверов произошло быстро. В марте 1996 года одна веб-хостинговая компания сообщила, что более 40% браузеров, используемых в Интернете, использовали новый заголовок HTTP/1.1 «Host» для включения виртуального хостинга , и что к июню 1996 года 65% всех браузеров, обращающихся к их серверам, были Совместимость с предварительным стандартом HTTP/1.1. [32]
В январе 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. [33]
Рабочая группа IETF HTTP перезапустила
В 2007 году рабочая группа IETF HTTP (HTTP WG bis или HTTPbis) была перезапущена, во-первых, для пересмотра и уточнения предыдущих спецификаций HTTP/1.1, а во-вторых, для написания и уточнения будущих спецификаций HTTP/2 (названных httpbis). [34] [35]
SPDY: неофициальный протокол HTTP, разработанный Google.
В 2009 году частная компания Google объявила, что разработала и протестировала новый двоичный протокол HTTP под названием SPDY . Неявной целью было значительно ускорить веб-трафик (особенно между будущими веб-браузерами и их серверами).
Во многих тестах SPDY действительно был намного быстрее, чем HTTP/1.1, поэтому он был быстро принят Chromium , а затем и другими основными веб-браузерами. [36]
Некоторые идеи о мультиплексировании потоков HTTP через одно соединение TCP/IP были взяты из различных источников, включая работу рабочей группы W3C HTTP-NG.
HTTP/2
В январе – марте 2012 года Рабочая группа HTTP (HTTPbis) объявила о необходимости сосредоточиться на новом протоколе HTTP/2 (завершая при этом пересмотр спецификаций HTTP/1.1), возможно, принимая во внимание идеи и работу, проделанную для SPDY. [37] [38]
После нескольких месяцев размышлений о том, что делать для разработки новой версии HTTP, было решено вывести ее из SPDY. [39]
В мае 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 (и выше): [40]

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

С 2016 года многие менеджеры по продуктам и разработчики пользовательских агентов (браузеров и т. д.) и веб-серверов начали планировать постепенное прекращение поддержки протокола HTTP/0.9, главным образом по следующим причинам: [41]
  • настолько просто, что документ RFC никогда не был написан (есть только исходный документ); [2]
  • в нем нет заголовков HTTP и многих других функций, которые в настоящее время необходимы из соображений минимальной безопасности;
  • он не получил широкого распространения с 1999 по 2000 год (из-за HTTP/1.0 и HTTP/1.1) и обычно используется только некоторым очень старым сетевым оборудованием, например маршрутизаторами и т. д.
[примечание 2]
HTTP/3
В 2020 году были опубликованы первые проекты HTTP/3 , и его начали использовать основные веб-браузеры и веб-серверы.
6 июня 2022 года IETF стандартизировал HTTP/3 как РФК   9114 . [42]
Обновления и рефакторинг в 2022 году
В июне 2022 года была опубликована серия RFC, в которой многие предыдущие документы признаны устаревшими и внесены несколько незначительных изменений и рефакторинг описания семантики HTTP в отдельный документ.

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

[ редактировать ]

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

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

[ редактировать ]

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

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

[ редактировать ]
Основная статья: постоянное соединение HTTP

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

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

В 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 обеспечивает общую структуру для управления доступом и аутентификации посредством расширяемого набора схем аутентификации запрос-ответ, которые могут использоваться сервером для запроса запроса клиента и клиентом для предоставления информации аутентификации. [1]

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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

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

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

[ редактировать ]

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

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

[ редактировать ]

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

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 в РФК   1945 . [47]

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

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

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

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

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

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

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

ПОМЕЩАТЬ
Метод PUT запрашивает, чтобы целевой ресурс создал или обновил свое состояние до состояния, определенного представлением, включенным в запрос. Отличие от POST заключается в том, что клиент указывает целевое расположение на сервере. [55]

УДАЛИТЬ
Метод DELETE запрашивает, чтобы целевой ресурс удалил свое состояние.

СОЕДИНЯТЬ
Метод CONNECT запрашивает, чтобы посредник установил туннель TCP/IP к исходному серверу, указанному в цели запроса. Он часто используется для защиты соединений через один или несколько HTTP-прокси с помощью TLS . [56] [57] См. метод HTTP CONNECT .

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

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

ПЛАСТЫРЬ
Метод PATCH запрашивает, чтобы целевой ресурс изменил свое состояние в соответствии с частичным обновлением, определенным в представлении, включенном в запрос. Это может сэкономить полосу пропускания за счет обновления части файла или документа без необходимости его полной передачи. [58]

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

Свойства методов запроса
Метод запроса 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, просто удалит статью. [59] На правильно закодированном веб-сайте для этого действия потребуется метод DELETE или POST, который не будут выполнять незлонамеренные боты.

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

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

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

Метод запроса является идемпотентным , если несколько идентичных запросов с этим методом имеют тот же эффект, что и один такой запрос. Методы 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

[ редактировать ]

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

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

[ редактировать ]

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

  • строка состояния , состоящая из версии протокола, пробела , кода состояния ответа , другого пробела, возможно пустой фразы причины, возврата каретки и перевода строки , например: 
    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. [примечание 5] [примечание 6]

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

[ редактировать ] 
GET / HTTP/1.1Host: www.example.comUser-Agent: Mozilla/5.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8Accept-Language: en-GB,en;q=0.5Accept-Encoding: gzip, deflate, brConnection: keep-alive

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

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

[ редактировать ] 
HTTP/1.1 200 OKDate: Mon, 23 May 2005 22:38:34 GMTContent-Type: text/html; charset=UTF-8Content-Length: 155Last-Modified: Wed, 08 Jan 2003 23:11:55 GMTServer: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)ETag: "3f80f-1b6-3e1cb03b"Accept-Ranges: bytesConnection: 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". Это полезно, если клиенту нужно иметь только определенные порции. [61] ресурса, отправленного сервером, что называется обслуживанием байтов . Когда "Connection: close" отправляется, это означает, что веб-сервер закроет TCP- соединение сразу после окончания передачи этого ответа. [21]

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

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

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

[ редактировать ]

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

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

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

См. также

[ редактировать ]
HTTP
Методы запроса
Поля заголовка
Коды статуса ответа
Методы безопасного контроля доступа
Уязвимости безопасности

Примечания

[ редактировать ]
  1. ^ На практике эти потоки используются как несколько подсоединений TCP/IP для мультиплексирования одновременных запросов/ответов, что значительно сокращает количество реальных соединений TCP/IP на стороне сервера с 2–8 на клиент до 1 и позволяет гораздо больше клиентов, которые будут обслуживаться одновременно.
  2. ^ В 2022 году поддержка HTTP/0.9 официально не была полностью прекращена и все еще присутствует на многих веб-серверах и браузерах (только для ответов сервера), даже если обычно отключена. Неясно, сколько времени потребуется для вывода из эксплуатации HTTP/0.9.
  3. ^ С конца 1996 года некоторые разработчики популярных браузеров и серверов HTTP/1.0 (особенно те, кто планировал поддержку HTTP/1.1) начали развертывать (в качестве неофициального расширения) своего рода механизм поддержания активности (с использованием новых HTTP-заголовки), чтобы соединение TCP/IP оставалось открытым более чем для пары запрос/ответ и, таким образом, ускоряло обмен несколькими запросами/ответами. [31]
  4. ^ Перейти обратно: а б HTTP/2 и HTTP/3 имеют разное представление методов и заголовков HTTP.
  5. ^ HTTP/1.0 имеет те же сообщения, за исключением нескольких отсутствующих заголовков.
  6. ^ HTTP/2 и HTTP/3 используют один и тот же механизм запроса/ответа, но с разными представлениями HTTP-заголовков.

Ссылки

[ редактировать ]
  1. ^ Перейти обратно: а б с д Филдинг, Р.; Ноттингем, М.; Решке, Дж. (июнь 2022 г.). HTTP-семантика . IETF. дои : 10.17487/RFC9110 . РФК 9110 .
  2. ^ Перейти обратно: а б с д Тим Бернер-Ли (1 января 1991 г.). «Оригинальный HTTP, определенный в 1991 году» . www.w3.org . Консорциум Всемирной паутины . Проверено 24 июля 2010 г.
  3. ^ Перейти обратно: а б Тим Бернер-Ли (1992). «Базовый HTTP, определенный в 1992 году» . www.w3.org . Консорциум Всемирной паутины . Проверено 19 октября 2021 г.
  4. ^ В РФК   1945 . Затем эта спецификация была преодолена HTTP/1.1.
  5. ^ RFC   2068 (1997) устарел. RFC   2616 1999 года, который устарел. RFC   7230 в 2014 году, который устарел. RFC   9110 в 2022 году.
  6. ^ «Статистика использования протокола https по умолчанию для веб-сайтов» . w3techs.com . Проверено 5 января 2024 г.
  7. ^ «Статистика использования HTTP/2 для веб-сайтов» . w3techs.com . Проверено 5 января 2024 г.
  8. ^ «Могу ли я использовать... Таблицы поддержки HTML5, CSS3 и т. д.» . caniuse.com . Проверено 5 января 2024 г.
  9. ^ Фридл, С.; Попов А.; Лэнгли, А.; Стефан, Э. (июль 2014 г.). Расширение согласования протокола уровня приложений (TLS) . IETF. дои : 10.17487/RFC7301 . РФК 7301 .
  10. ^ Бельше, М.; Пеон, Р.; Томсон, М. «Протокол передачи гипертекста версии 2, использование функций TLS» . Архивировано из оригинала 15 июля 2013 г. Проверено 10 февраля 2015 г.
  11. ^ Бенджамин, Дэвид. Использование TLS 1.3 с HTTP/2 . дои : 10.17487/RFC8740 . РФК 8740 . Проверено 2 июня 2020 г. Это снижает барьер для развертывания TLS 1.3, что является значительным улучшением безопасности по сравнению с TLS 1.2.
  12. ^ HTTP/3 . 6 июня 2022 г. doi : 10.17487/RFC9114 . РФК 9114 . Проверено 6 июня 2022 г.
  13. ^ «Статистика использования HTTP/3 для веб-сайтов» . w3techs.com . Проверено 08 января 2024 г.
  14. ^ «Могу ли я использовать... Таблицы поддержки HTML5, CSS3 и т. д.» . canIuse.com . Проверено 08 января 2024 г.
  15. ^ Чимпану, Каталин (26 сентября 2019 г.). «Cloudflare, Google Chrome и Firefox добавляют поддержку HTTP/3» . ЗДНет . Проверено 27 сентября 2019 г.
  16. ^ «HTTP/3: прошлое, настоящее и будущее» . Блог Cloudflare . 26 сентября 2019 г. Проверено 30 октября 2019 г.
  17. ^ «Firefox Nightly поддерживает HTTP 3 – Общие сведения – Сообщество Cloudflare» . 19.11.2019 . Проверено 23 января 2020 г.
  18. ^ «HTTP/3 — это быстро» . Запросить метрики . Проверено 1 июля 2022 г.
  19. ^ Перейти обратно: а б с «Соединения, клиенты и серверы» . RFC 9110, Семантика HTTP . сек. 3.3. дои : 10.17487/RFC9110 . РФК 9110 .
  20. ^ «Общая операция» . РФК 1945 . стр. 6–8. сек. 1.3. дои : 10.17487/RFC1945 . РФК 1945 .
  21. ^ Перейти обратно: а б с «Управление соединениями: Установление» . RFC 9112, HTTP/1.1 . сек. 9.1. дои : 10.17487/RFC9112 . РФК 9112 .
  22. ^ «Управление соединениями: постоянство» . RFC 9112, HTTP/1.1 . сек. 9.3. дои : 10.17487/RFC9112 . РФК 9112 .
  23. ^ «Классические HTTP-документы» . W3.org. 14 мая 1998 г. Проверено 1 августа 2010 г.
  24. ^ «Обзор протокола HTTP/2» . RFC 9113, HTTP/2) . сек. 2. дои : 10.17487/RFC7540 . РФК 7540 .
  25. ^ «Изобретение Интернета, история Интернета, кто изобрел Интернет, Тим Бернерс-Ли, Роберт Кайо, ЦЕРН, Первый веб-сервер» . Живой Интернет . Проверено 11 августа 2021 г.
  26. ^ Бернерс-Ли, Тим (2 октября 1990 г.). «daemon.c — сервер для гипертекста на основе TCP/IP» . www.w3.org . Проверено 11 августа 2021 г.
  27. ^ Бернерс-Ли, Тим. «Протокол передачи гипертекста» . Консорциум Всемирной паутины . Проверено 31 августа 2010 г.
  28. ^ Рэггетт, Дэйв. «Биография Дэйва Рэггетта» . Консорциум Всемирной паутины . Проверено 11 июня 2010 г.
  29. ^ Рэггетт, Дэйв; Бернерс-Ли, Тим. «Рабочая группа по протоколу передачи гипертекста» . Консорциум Всемирной паутины . Проверено 29 сентября 2010 г.
  30. ^ Рэггетт, Дэйв. «Планы рабочей группы HTTP» . Консорциум Всемирной паутины . Проверено 29 сентября 2010 г.
  31. ^ Перейти обратно: а б Дэвид Горли; Брайан Тотти; Марджори Сэйер; Аншу Аггарвал; Сайлу Редди (2002). HTTP: Полное руководство. (отрывок из главы: «Постоянные соединения») . О'Рейли Медиа, Inc. ISBN  9781565925090 . Проверено 18 октября 2021 г.
  32. ^ «HTTP 1.1-совместимые браузеры» . вебком.com . Архивировано из оригинала 4 февраля 1998 г. Проверено 29 мая 2009 г.
  33. ^ «Рабочая группа HTTP-NG» . www.w3.org . Консорциум Всемирной паутины. 1997 год . Проверено 19 октября 2021 г.
  34. ^ Веб-администратор (2007). «Рабочая группа HTTP» . httpwg.org . IETF . Проверено 19 октября 2021 г.
  35. ^ Перейти обратно: а б Веб-администратор (2007). «Рабочая группа HTTP: устав httpbis» . datatracker.ietf.org . IETF . Проверено 19 октября 2021 г.
  36. ^ «SPDY: экспериментальный протокол для более быстрого Интернета» . dev.chromium.org . Google. 01.11.2009 . Проверено 19 октября 2021 г.
  37. ^ «Перезарядка httpbis» . IETF; HTTP-РГ. 24 января 2012 г. Проверено 19 октября 2021 г.
  38. ^ Секретарь IESG (19 марта 2012 г.). «Действие рабочей группы: RECHARTER: Протокол передачи гипертекста Bis (httpbis)» . IETF; HTTP-РГ . Проверено 19 октября 2021 г.
  39. ^ Илья Григорик; Сурма (03.09.2019). «Высокопроизводительная браузерная сеть: введение в HTTP/2» . Developers.google.com . Гугл Инк . Проверено 19 октября 2021 г.
  40. ^ «Приложение-A: История версий HTTP» . RFC 7230, HTTP/1.1: Синтаксис сообщений и маршрутизация . п. 78. сек. А. дои : 10.17487/RFC7230 . РФК 7230 .
  41. ^ Мэтт Менке (30 июня 2016 г.). «Намерение объявить устаревшим и удалить: поддержка HTTP/0.9» . groups.google.com . Проверено 15 октября 2021 г.
  42. ^ HTTP/3 . 6 июня 2022 г. doi : 10.17487/RFC9114 . РФК 9114 . Проверено 6 июня 2022 г.
  43. ^ «http URI-схема» . RFC 9110, Семантика HTTP . сек. 4.2.1. дои : 10.17487/RFC9110 . РФК 9110 .
  44. ^ «Схема URI https» . RFC 9110, Семантика HTTP . сек. 4.2.2. дои : 10.17487/RFC9110 . РФК 9110 .
  45. ^ Ли, Вэй-Бин; Чен, Син-Бай; Чанг, Шун-Шян; Чен, Цунг-Хер (25 января 2019 г.). «Безопасная и эффективная защита файлов cookie HTTP с самопроверкой» . Международный журнал систем связи . 32 (2): e3857. дои : 10.1002/dac.3857 . S2CID   59524143 .
  46. ^ Перейти обратно: а б «Формат сообщения» . RFC 9112: HTTP/1.1 . сек. 2.1. дои : 10.17487/RFC9112 . РФК 9112 .
  47. ^ «Неделя Apache. HTTP/1.1» . Архивировано из оригинала 2 июня 2021 г. Проверено 03 мая 2021 г. 090502 apacheweek.com
  48. ^ Бернерс-Ли, Тим; Филдинг, Рой Т.; Нильсен, Хенрик Фристик. «Определения методов» . Протокол передачи гипертекста — HTTP/1.0 . IETF. стр. 30–32. сек. 8. дои : 10.17487/RFC1945 . РФК 1945 .
  49. ^ «Определения методов» . РФК 2616 . стр. 51–57. сек. 9. дои : 10.17487/RFC2616 . РФК 2616 .
  50. ^ «Линия запроса» . RFC 9112, HTTP/1.1 . сек. 3. дои : 10.17487/RFC9112 . РФК 9112 .
  51. ^ Перейти обратно: а б «Методы: Обзор» . RFC 9110, Семантика HTTP . сек. 9.1. дои : 10.17487/RFC9110 . РФК 9110 .
  52. ^ «Поля заголовка» . RFC 9110, Семантика HTTP . сек. 6.3. дои : 10.17487/RFC9110 . РФК 9110 .
  53. ^ Джейкобс, Ян (2004). «URI, адресация и использование HTTP GET и POST» . Заключение группы технической архитектуры . W3C . Проверено 26 сентября 2010 г.
  54. ^ "ПОЧТА" . RFC 9110, Семантика HTTP . сек. 9.3.3. дои : 10.17487/RFC9110 . РФК 9110 .
  55. ^ "ПОМЕЩАТЬ" . RFC 9110, Семантика HTTP . сек. 9.3.4. дои : 10.17487/RFC9110 . РФК 9110 .
  56. ^ "СОЕДИНЯТЬ" . RFC 9110, Семантика HTTP . сек. 9.3.6. дои : 10.17487/RFC9110 . РФК 9110 .
  57. ^ «Примечание об уязвимости VU#150227: конфигурации HTTP-прокси по умолчанию допускают произвольные TCP-соединения» . США-СЕРТ . 17 мая 2002 г. Проверено 10 мая 2007 г.
  58. ^ Дюссо, Лиза; Снелл, Джеймс М. (март 2010 г.). PATCH Метод для HTTP . IETF. дои : 10.17487/RFC5789 . РФК 5789 .
  59. ^ Перейти обратно: а б Эдигер, Брэд (21 декабря 2007 г.). Advanced Rails: создание промышленных веб-приложений в рекордно короткие сроки . О'Рейли Медиа, Инк. с. 188. ИСБН  978-0596519728 . Распространенной ошибкой является использование GET для действия по обновлению ресурса. [...] Эта проблема привлекла внимание общественности Rails в 2005 году, когда был выпущен Google Web Accelerator.
  60. ^ Кантрелл, Кристиан (1 июня 2005 г.). «Чему мы научились благодаря веб-ускорителю Google?» . Блоги Adobe . Adobe. Архивировано из оригинала 19 августа 2017 г. Проверено 19 ноября 2018 г.
  61. ^ Луотонен, Ари; Фрэнкс, Джон (22 февраля 1996 г.). Расширение получения диапазона байтов для HTTP . IETF. Идентификатор черновика-ietf-http-range-retrival-00.
  62. ^ Канаван, Джон (2001). Основы сетевой безопасности . Норвуд, Массачусетс: Artech House. стр. 82–83. ISBN  9781580531764 .
  63. ^ Залевский, Михал. «Справочник по безопасности браузера» . Проверено 30 апреля 2015 г.
  64. ^ «Проблема Chromium 4527: реализация RFC 2817: обновление до TLS в HTTP/1.1» . Проверено 30 апреля 2015 г.
  65. ^ «Ошибка Mozilla 276813 — [RFE] Поддержка обновления RFC 2817/TLS для HTTP 1.1» . Проверено 30 апреля 2015 г.
  66. ^ Ноттингем, Марк (октябрь 2010 г.). Веб-ссылки . IETF. дои : 10.17487/RFC5988 . РФК 5988 .
[ редактировать ]
В Wikibooks есть книга на тему: Сети связи/Протокол HTTP.
Викискладе есть медиафайлы, связанные с протоколом передачи гипертекста .


Retrieved from "https://en.wikipedia.org/w/index.php?title=HTTP&oldid=1237016442"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: 1cd2e39cca8c923d158120c73f54c9bb__1722093000
URL1:https://arc.ask3.ru/arc/aa/1c/bb/1cd2e39cca8c923d158120c73f54c9bb.html
Заголовок, (Title) документа по адресу, URL1:
HTTP - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)