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 года [update]его поддерживают 66,2% веб-сайтов [7] [8] (35,3% HTTP/2 + 30,9% HTTP/3 с обратной совместимостью) и поддерживают почти все веб-браузеры (более 98% пользователей). [9] Он также поддерживается основными веб-серверами по протоколу Transport Layer Security (TLS) с использованием расширения Application-Layer Protocol Negotiation (ALPN) [10] , где требуется TLS 1.2 или более новая версия. [11] [12]
HTTP/3 , преемник HTTP/2, был опубликован в 2022 году. [13] По состоянию на февраль 2024 года [update]он теперь используется на 30,9% веб-сайтов [14] и поддерживается большинством веб-браузеров, т. е. (по крайней мере частично) поддерживается 97% пользователей. [15] HTTP/3 использует QUIC вместо TCP для базового транспортного протокола. Как и HTTP/2, он не отменяет предыдущие основные версии протокола. Поддержка HTTP/3 была добавлена в Cloudflare и Google Chrome в первую очередь, [16] [17] а также включена в Firefox . [18] HTTP/3 имеет меньшую задержку для реальных веб-страниц, если включен на сервере, и загружается быстрее, чем с HTTP/2, в некоторых случаях более чем в три раза быстрее, чем HTTP/1.1 (который до сих пор обычно только включен). [19]
HTTP функционирует как протокол запрос-ответ в модели клиент-сервер . Например, веб-браузер может быть клиентом , тогда как процесс , называемый веб-сервером , работающий на компьютере, на котором размещен один или несколько веб-сайтов, может быть сервером . Клиент отправляет сообщение HTTP- запроса на сервер. Сервер, который предоставляет ресурсы, такие как файлы HTML и другой контент, или выполняет другие функции от имени клиента, возвращает клиенту ответное сообщение. Ответ содержит информацию о статусе завершения запроса и может также содержать запрошенный контент в теле сообщения.
Веб-браузер является примером пользовательского агента (UA). Другие типы пользовательских агентов включают индексирующее программное обеспечение, используемое поисковыми провайдерами ( веб-краулеры ), голосовые браузеры , мобильные приложения и другое программное обеспечение , которое получает доступ, потребляет или отображает веб-контент.
HTTP разработан для того, чтобы позволить промежуточным сетевым элементам улучшить или включить связь между клиентами и серверами. Высокотрафикные веб-сайты часто выигрывают от веб-серверов кэширования , которые доставляют контент от имени вышестоящих серверов для улучшения времени отклика. Веб-браузеры кэшируют ранее использованные веб-ресурсы и повторно используют их, когда это возможно, для сокращения сетевого трафика. HTTP- прокси-серверы на границах частной сети могут облегчить связь для клиентов без глобально маршрутизируемого адреса, передавая сообщения внешним серверам.
Чтобы промежуточные HTTP-узлы (прокси-серверы, веб-кэши и т. д.) могли выполнять свои функции, некоторые HTTP-заголовки (встречающиеся в HTTP-запросах/ответах) управляются пошагово, тогда как другие HTTP-заголовки управляются сквозным образом (управляются только исходным клиентом и целевым веб-сервером).
HTTP — это протокол прикладного уровня , разработанный в рамках набора протоколов Интернета . Его определение предполагает базовый и надежный протокол транспортного уровня . [20] В HTTP/3 протокол управления передачей (TCP) больше не используется, но старые версии все еще используются чаще и они чаще всего используют TCP. Они также были адаптированы для использования ненадежных протоколов, таких как протокол пользовательских датаграмм (UDP), на котором HTTP/3 также (косвенно) всегда строится, например, в HTTPU и простом протоколе обнаружения служб (SSDP).
HTTP-ресурсы идентифицируются и размещаются в сети с помощью унифицированных указателей ресурсов (URL), использующих схемы унифицированных идентификаторов ресурсов (URI) http и https . Как определено в RFC 3986, URI кодируются как гиперссылки в HTML- документах, чтобы сформировать взаимосвязанные гипертекстовые документы.
В HTTP/1.0 для каждого запроса ресурса создается отдельное TCP- соединение с тем же сервером. [21]
В HTTP/1.1 вместо этого TCP-соединение может быть повторно использовано для выполнения нескольких запросов ресурсов (например, HTML-страниц, фреймов, изображений, скриптов , таблиц стилей и т. д.). [22] [23]
Поэтому HTTP/1.1-коммуникации испытывают меньшую задержку , поскольку установление TCP-соединений сопряжено со значительными накладными расходами, особенно в условиях интенсивного трафика. [24]
HTTP/2 — это переработанный вариант предыдущего HTTP/1.1, сохраняющий ту же модель клиент-сервер и те же методы протокола, но со следующими отличиями в следующем порядке:
Поэтому при обмене данными по протоколу HTTP/2 задержка значительно меньше, а скорость в большинстве случаев даже выше, чем при обмене данными по протоколу HTTP/1.1.
HTTP/3 — это пересмотр предыдущего HTTP/2 с целью использования транспортных протоколов QUIC + UDP вместо TCP. До этой версии использовались соединения TCP/IP; но теперь используется только уровень IP (на котором, как и TCP, построен UDP). Это немного улучшает среднюю скорость связи и позволяет избежать случайной (очень редкой) проблемы перегрузки соединения TCP , которая может временно блокировать или замедлять поток данных всех его потоков (еще одна форма « блокировки начала очереди »).
Термин гипертекст был придуман Тедом Нельсоном в 1965 году в проекте Xanadu , который, в свою очередь, был вдохновлен видением Ванневара Буша 1930-х годов системы поиска и управления информацией на основе микрофильмов « memex », описанной в его эссе 1945 года « As We May Think ». Тиму Бернерсу-Ли и его команде в ЦЕРНе приписывают изобретение оригинального HTTP, а также HTML и связанной с ним технологии для веб-сервера и клиентского пользовательского интерфейса, называемого веб-браузером . Бернерс-Ли разработал HTTP, чтобы помочь с принятием его другой идеи: проекта «WorldWideWeb», который был впервые предложен в 1989 году, теперь известного как Всемирная паутина .
Первый веб-сервер был запущен в 1990 году. [26] [27] Используемый протокол имел только один метод, а именно GET, который запрашивал страницу с сервера. [28] Ответом от сервера всегда была HTML-страница. [2]
В 1991 году первая задокументированная официальная версия HTTP была написана в виде простого документа длиной менее 700 слов, и эта версия была названа HTTP/0.9, которая поддерживала только метод GET, позволяя клиентам только извлекать HTML-документы с сервера, но не поддерживая никаких других форматов файлов или загрузку информации. [2]
С 1992 года был написан новый документ, определяющий эволюцию базового протокола в направлении его следующей полной версии. Он поддерживал как простой метод запроса версии 0.9, так и полный запрос GET, включающий клиентскую версию HTTP. Это был первый из многих неофициальных черновиков HTTP/1.0, которые предшествовали окончательной работе над HTTP/1.0. [3]
После того, как было принято решение о необходимости внедрения новых функций протокола HTTP и о том, что они должны быть полностью документированы в качестве официальных документов RFC , в начале 1995 года была создана рабочая группа HTTP (HTTP WG, возглавляемая Дейвом Рэггеттом ) с целью стандартизации и расширения протокола с помощью расширенных операций, расширенного согласования, более богатой метаинформации, связанной с протоколом безопасности, который стал более эффективным за счет добавления дополнительных методов и полей заголовков . [29] [30]
Рабочая группа HTTP планировала пересмотреть и опубликовать новые версии протокола как HTTP/1.0 и HTTP/1.1 в течение 1995 года, но из-за многочисленных изменений этот график растянулся намного больше, чем на один год. [31]
Рабочая группа HTTP также планировала разработать версию HTTP в далеком будущем под названием HTTP-NG (HTTP Next Generation), которая решила бы все оставшиеся проблемы предыдущих версий, связанные с производительностью, малой задержкой ответов и т. д. Однако эта работа началась лишь несколько лет спустя и так и не была завершена.
В мае 1996 года был опубликован RFC 1945 как окончательная редакция HTTP/1.0 того, что использовалось в течение предыдущих 4 лет в качестве предстандартного проекта HTTP/1.0, который уже использовался многими веб-браузерами и веб-серверами.
В начале 1996 года разработчики начали даже включать неофициальные расширения протокола HTTP/1.0 (например, соединения keep-alive и т. д.) в свои продукты, используя проекты будущих спецификаций HTTP/1.1. [32]
С начала 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.
Продолжая старый план предыдущей рабочей группы HTTP 1995 года, в 1997 году была сформирована рабочая группа HTTP-NG для разработки нового протокола HTTP под названием HTTP-NG (HTTP New Generation). Было подготовлено несколько предложений/черновиков для нового протокола, чтобы использовать мультиплексирование транзакций HTTP внутри одного соединения TCP/IP, но в 1999 году группа прекратила свою деятельность, передав технические проблемы в IETF. [34]
В 2007 году рабочая группа IETF HTTP (HTTP WG bis или HTTPbis) была перезапущена, во-первых, для пересмотра и уточнения предыдущих спецификаций HTTP/1.1, а во-вторых, для написания и уточнения будущих спецификаций HTTP/2 (названных httpbis). [35] [36]
В 2009 году частная компания Google объявила, что разработала и протестировала новый двоичный протокол HTTP под названием SPDY . Неявной целью было значительное ускорение веб-трафика (особенно между будущими веб-браузерами и их серверами).
SPDY действительно оказался намного быстрее HTTP/1.1 во многих тестах, поэтому его быстро приняли в Chromium , а затем и в других основных веб-браузерах. [37]
Некоторые идеи о мультиплексировании потоков HTTP по одному соединению TCP/IP были взяты из различных источников, включая работу рабочей группы W3C HTTP-NG.
В январе–марте 2012 года рабочая группа HTTP (HTTPbis) объявила о необходимости начать концентрироваться на новом протоколе HTTP/2 (завершая пересмотр спецификаций HTTP/1.1), возможно, принимая во внимание идеи и работу, проделанную для SPDY. [38] [39]
После нескольких месяцев раздумий о том, что делать с разработкой новой версии HTTP, было решено вывести ее из SPDY. [40]
В мае 2015 года HTTP/2 был опубликован как RFC 7540 и быстро принят всеми веб-браузерами, уже поддерживающими SPDY, и несколько медленнее — веб-серверами.
В июне 2014 года рабочая группа HTTP выпустила обновленную спецификацию HTTP/1.1 из шести частей, отменяющую RFC 2616:
В 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]
[примечание 2]
В 2020 году были опубликованы первые черновики HTTP/3 , и основные веб-браузеры и веб-серверы начали его внедрять.
6 июня 2022 года IETF стандартизировал HTTP/3 как RFC 9114. [43]
В июне 2022 года был опубликован пакет RFC, объявляющий устаревшими многие из предыдущих документов и вносящий несколько незначительных изменений и рефакторинг описания семантики HTTP в отдельный документ.
HTTP — это протокол уровня приложения без сохранения состояния , требующий надежного сетевого транспортного соединения для обмена данными между клиентом и сервером. [20] В реализациях HTTP соединения TCP/IP используются с использованием известных портов (обычно порт 80 , если соединение не зашифровано, или порт 443, если соединение зашифровано, см. также Список номеров портов TCP и UDP ). [44] [45] В HTTP/2 используются соединение TCP/IP и несколько каналов протоколов. В HTTP/3 используется протокол транспортного уровня приложения QUIC через UDP.
Данные обмениваются через последовательность сообщений типа «запрос-ответ» , которые обмениваются транспортным соединением сеансового уровня . [20] HTTP-клиент сначала пытается подключиться к серверу, устанавливая соединение (реальное или виртуальное). HTTP(S)-сервер, прослушивающий этот порт, принимает соединение, а затем ждет сообщения-запроса клиента. Клиент отправляет свое сообщение-запрос HTTP. Получив запрос, сервер отправляет обратно сообщение-ответ HTTP, которое включает заголовок(и) и тело, если это требуется. Тело этого сообщения-ответа обычно является запрошенным ресурсом, хотя также может быть возвращено сообщение об ошибке или другая информация. В любое время (по многим причинам) клиент или сервер могут закрыть соединение. Закрытие соединения обычно объявляется заранее с помощью одного или нескольких заголовков HTTP в последнем сообщении-запросе/ответе, отправленном серверу или клиенту. [22]
В HTTP/0.9 соединение TCP/IP всегда закрывается после отправки ответа сервера, поэтому оно никогда не является постоянным.
В HTTP/1.0 , как указано в RFC 1945, соединение TCP/IP всегда должно быть закрыто сервером после отправки ответа. [примечание 3]
В HTTP/1.1 был официально представлен механизм keep-alive, чтобы соединение можно было повторно использовать для более чем одного запроса/ответа. Такие постоянные соединения ощутимо сокращают задержку запроса , поскольку клиенту не нужно повторно согласовывать соединение TCP 3-Way-Handshake после отправки первого запроса. Другим положительным побочным эффектом является то, что в целом соединение со временем становится быстрее из-за механизма медленного старта TCP .
HTTP/1.1 также добавил HTTP-конвейеризацию для дальнейшего сокращения времени задержки при использовании постоянных соединений, позволяя клиентам отправлять несколько запросов перед ожиданием каждого ответа. Эта оптимизация никогда не считалась действительно безопасной, поскольку несколько веб-серверов и множество прокси-серверов , особенно прозрачных прокси-серверов, размещенных в Интернете / интрасетях между клиентами и серверами, не обрабатывали конвейерные запросы должным образом (они обслуживали только первый запрос, отбрасывая другие, они закрывали соединение, потому что видели больше данных после первого запроса, или некоторые прокси даже возвращали ответы не по порядку и т. д.). Из-за этого только HEAD- и некоторые GET-запросы (т. е. ограниченные реальными запросами файлов и, следовательно, URL-адресами без строки запроса, используемой в качестве команды и т. д.) могли быть конвейеризированы в безопасном и идемпотентном режиме. После многих лет борьбы с проблемами, вызванными включением конвейеризации, эта функция была сначала отключена, а затем удалена из большинства браузеров также из-за объявленного принятия HTTP/2.
HTTP/2 расширил возможности использования постоянных соединений за счет мультиплексирования множества одновременных запросов/ответов через одно соединение TCP/IP.
HTTP/3 не использует соединения TCP/IP, а использует QUIC + UDP (см. также: технический обзор).
"Content-Length: number"отсутствовал в заголовках HTTP, и клиент предполагал, что когда сервер закрыл соединение, содержимое было отправлено целиком. Этот механизм не мог отличить успешно завершенную передачу ресурса от прерванной (из-за ошибки сервера/сети или чего-то еще).HTTP предоставляет несколько схем аутентификации, таких как базовая аутентификация доступа и дайджест-аутентификация доступа , которые работают с помощью механизма «запрос-ответ», при котором сервер идентифицирует и отправляет запрос перед обслуживанием запрошенного контента.
HTTP обеспечивает общую структуру для контроля доступа и аутентификации с помощью расширяемого набора схем аутентификации «вызов-ответ», которые могут использоваться сервером для проверки клиентского запроса, а клиентом — для предоставления информации об аутентификации. [1]
Описанные выше механизмы аутентификации относятся к протоколу HTTP и управляются клиентским и серверным программным обеспечением HTTP (если оно настроено на требование аутентификации перед предоставлением клиенту доступа к одному или нескольким веб-ресурсам), а не веб-приложениями, использующими сеанс веб-приложения.
Спецификация HTTP Authentication также предоставляет произвольную, специфичную для реализации конструкцию для дальнейшего разделения ресурсов, общих для данного корневого URI . Строка значения области, если она присутствует, объединяется с каноническим корневым URI для формирования компонента пространства защиты вызова. Это фактически позволяет серверу определять отдельные области аутентификации под одним корневым URI. [1]
HTTP — это протокол без сохранения состояния . Протокол без сохранения состояния не требует от веб-сервера сохранять информацию или статус о каждом пользователе на протяжении нескольких запросов.
Некоторым веб-приложениям необходимо управлять сеансами пользователей, поэтому они реализуют состояния или сеансы на стороне сервера , используя, например, файлы cookie HTTP [46] или скрытые переменные в веб-формах .
Для запуска сеанса пользователя приложения необходимо выполнить интерактивную аутентификацию через вход в веб-приложение. Для остановки сеанса пользователя необходимо запросить операцию выхода из системы пользователем. Такие операции не используют HTTP-аутентификацию, а настраиваемую аутентификацию веб-приложения.
Сообщения-запросы отправляются клиентом на целевой сервер. [примечание 4]
Клиент отправляет серверу сообщения-запросы , которые состоят из: [47]
ПОЛУЧИТЬ /images/logo.png HTTP / 1.1Хост: www.example.comПринять-Язык: ru
В протоколе HTTP/1.1 все поля заголовка, за исключением , Host: hostnameявляются необязательными.
Строка запроса, содержащая только имя пути, принимается серверами для поддержания совместимости с HTTP-клиентами до спецификации HTTP/1.0 в RFC 1945. [48]
HTTP определяет методы (иногда называемые глаголами , но нигде в спецификации не упоминается глагол ), чтобы указать желаемое действие, которое должно быть выполнено над идентифицированным ресурсом. Что представляет собой этот ресурс, будь то уже существующие данные или данные, которые генерируются динамически, зависит от реализации сервера. Часто ресурс соответствует файлу или выводу исполняемого файла, находящегося на сервере. Спецификация HTTP/1.0 [49] определила методы GET, HEAD и POST, а также перечислила методы PUT, DELETE, LINK и UNLINK в дополнительных методах. Однако спецификация HTTP/1.1 [50] формально определила и добавила пять новых методов: PUT, DELETE, CONNECT, OPTIONS и TRACE. Любой клиент может использовать любой метод, а сервер можно настроить для поддержки любой комбинации методов. Если метод неизвестен промежуточному элементу, он будет рассматриваться как небезопасный и неидемпотентный метод. Нет ограничений на количество методов, которые можно определить, что позволяет определять будущие методы без нарушения существующей инфраструктуры. Например, WebDAV определил семь новых методов, а RFC 5789 указал метод PATCH .
Имена методов чувствительны к регистру. [51] [52] Это отличается от имен полей заголовка HTTP, которые нечувствительны к регистру. [53]
Content-Length).Все веб-серверы общего назначения должны реализовывать как минимум методы GET и HEAD, а все остальные методы считаются необязательными в спецификации. [52]
Метод запроса безопасен , если запрос с этим методом не имеет предполагаемого эффекта на сервере. Методы GET, HEAD, OPTIONS и TRACE определены как безопасные. Другими словами, безопасные методы предназначены только для чтения . Безопасные методы все еще могут иметь побочные эффекты, невидимые клиенту, такие как добавление информации о запросе в файл журнала или списание средств с рекламного аккаунта .
Напротив, методы POST, PUT, DELETE, CONNECT и PATCH не являются безопасными. Они могут изменить состояние сервера или иметь другие эффекты, такие как отправка электронного письма . Поэтому такие методы обычно не используются соответствующими веб-роботами или веб-сканерами; некоторые из тех, которые не соответствуют, имеют тенденцию делать запросы без учета контекста или последствий.
Несмотря на предписанную безопасность запросов GET, на практике их обработка сервером технически не ограничена каким-либо образом. Небрежное или преднамеренно нерегулярное программирование может позволить запросам GET вызывать нетривиальные изменения на сервере. Это не рекомендуется из-за проблем, которые могут возникнуть, когда веб-кэширование , поисковые системы и другие автоматизированные агенты вносят непреднамеренные изменения на сервере. Например, веб-сайт может разрешить удаление ресурса через URL, такой как https://example.com/article/1234/delete , который, если его произвольно извлечь, даже с использованием GET, просто удалит статью. [60] Правильно закодированный веб-сайт потребует метода DELETE или POST для этого действия, чего не будут делать невредоносные боты.
Одним из примеров этого на практике был период недолгой бета-версии Google Web Accelerator , которая предварительно выбирала произвольные URL-адреса на просматриваемой пользователем странице, что приводило к автоматическому изменению или массовому удалению записей . Бета-версия была приостановлена всего через несколько недель после ее первого выпуска из-за широкой критики. [61] [60]
Метод запроса является идемпотентным, если несколько идентичных запросов с этим методом имеют тот же эффект, что и один такой запрос. Методы PUT и DELETE, а также безопасные методы определяются как идемпотентные. Безопасные методы тривиально идемпотентны, поскольку они не должны оказывать никакого влияния на сервер; методы PUT и DELETE, тем временем, являются идемпотентными, поскольку последовательные идентичные запросы будут игнорироваться. Например, веб-сайт может настроить конечную точку PUT для изменения записанного адреса электронной почты пользователя. Если эта конечная точка настроена правильно, любые запросы, которые просят изменить адрес электронной почты пользователя на тот же адрес электронной почты, который уже записан — например, дублирующие запросы после успешного запроса — не будут иметь никакого эффекта. Аналогично, запрос на УДАЛИТЬ определенного пользователя не будет иметь никакого эффекта, если этот пользователь уже был удален.
Напротив, методы POST, CONNECT и PATCH не обязательно идемпотентны, и поэтому отправка идентичного запроса POST несколько раз может дополнительно изменить состояние сервера или иметь дополнительные эффекты, такие как отправка нескольких писем . В некоторых случаях это желаемый эффект, но в других случаях это может произойти случайно. Например, пользователь может непреднамеренно отправить несколько запросов POST, нажав кнопку еще раз, если ему не дали четкого ответа о том, что первый щелчок обрабатывается. Хотя веб-браузеры могут показывать диалоговые окна с предупреждениями , чтобы предупредить пользователей в некоторых случаях, когда перезагрузка страницы может повторно отправить запрос POST, обычно веб-приложение должно обрабатывать случаи, когда запрос POST не должен быть отправлен более одного раза.
Обратите внимание, что то, является ли метод идемпотентным или нет, не навязывается протоколом или веб-сервером. Вполне возможно написать веб-приложение, в котором (например) вставка в базу данных или другое неидемпотентное действие запускается запросом GET или другим запросом. Однако, если сделать это вопреки рекомендациям, это может привести к нежелательным последствиям, если пользовательский агент предполагает, что повторение того же запроса безопасно, когда это не так.
Метод запроса является кэшируемым , если ответы на запросы с этим методом могут быть сохранены для будущего повторного использования. Методы GET, HEAD и POST определены как кэшируемые.
Напротив, методы PUT, DELETE, CONNECT, OPTIONS, TRACE и PATCH не кэшируются.
Поля заголовка запроса позволяют клиенту передавать дополнительную информацию за пределы строки запроса, выступая в качестве модификаторов запроса (аналогично параметрам процедуры). Они предоставляют информацию о клиенте, о целевом ресурсе или об ожидаемой обработке запроса.
Ответное сообщение отправляется сервером клиенту в ответ на его предыдущее сообщение-запрос. [примечание 4]
Сервер отправляет клиенту ответные сообщения , которые состоят из: [47]
HTTP / 1.1 200 ОКТип содержимого: text/htmlВ HTTP/1.0 и более поздних версиях первая строка ответа HTTP называется строкой статуса и включает числовой код статуса (например, « 404 ») и текстовую фразу причины (например, «Not Found»). Код статуса ответа — это трехзначный целочисленный код, представляющий результат попытки сервера понять и удовлетворить соответствующий запрос клиента. То, как клиент обрабатывает ответ, зависит в первую очередь от кода статуса и, во вторую очередь, от других полей заголовка ответа. Клиенты могут не понимать все зарегистрированные коды статуса, но они должны понимать свой класс (заданный первой цифрой кода статуса) и рассматривать нераспознанный код статуса как эквивалент кода статуса x00 этого класса.
Стандартные фразы причины являются только рекомендациями и могут быть заменены «локальными эквивалентами» по усмотрению веб-разработчика . Если код состояния указывает на проблему, пользовательский агент может отобразить фразу причины пользователю, чтобы предоставить дополнительную информацию о характере проблемы. Стандарт также позволяет пользовательскому агенту попытаться интерпретировать фразу причины , хотя это может быть неразумно, поскольку стандарт явно указывает, что коды состояния являются машиночитаемыми, а фразы причины — человекочитаемыми.
Первая цифра кода статуса определяет его класс:
1XX(информационный)2XX(успешный)3XX(перенаправление)4XX(ошибка клиента)5XX(ошибка сервера)Поля заголовка ответа позволяют серверу передавать дополнительную информацию за пределы строки статуса, выступая в качестве модификаторов ответа. Они предоставляют информацию о сервере или о дальнейшем доступе к целевому ресурсу или связанным ресурсам.
Каждое поле заголовка ответа имеет определенное значение, которое может быть дополнительно уточнено семантикой метода запроса или кодом статуса ответа.
Ниже приведен пример HTTP-транзакции между клиентом HTTP/1.1 и сервером HTTP/1.1, работающим на www.example.com , порт 80. [примечание 5] [примечание 6]
GET / HTTP / 1.1 Хост : www.example.com User-Agent : Mozilla/5.0 Accept : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language : en-GB,en;q=0.5 Accept-Encoding : gzip, deflate, br Connection : keep-aliveЗа клиентским запросом (состоящим в данном случае из строки запроса и нескольких заголовков, которые можно сократить до одного "Host: hostname"заголовка) следует пустая строка, так что запрос заканчивается двойным концом строки, каждый в форме возврата каретки , за которым следует перевод строки . "Host: hostname"Значение заголовка различает различные имена DNS , разделяющие один IP-адрес , что позволяет организовать виртуальный хостинг на основе имени . Хотя в HTTP/1.0 это необязательно, в HTTP/1.1 это обязательно. (А "/" (косая черта) обычно извлекает файл /index.html , если он есть.)
HTTP / 1.1 200 OK Дата : Пн, 23 мая 2005 г. 22:38:34 GMT Тип содержимого : text/html; кодировка=UTF-8 Длина содержимого : 155 Последнее изменение : Ср, 08 января 2003 г. 23:11:55 GMT Сервер : Apache/1.3.3.7 (Unix) (Red-Hat/Linux) ETag : "3f80f-1b6-3e1cb03b" Диапазоны приема : байты Подключение : закрыть< html > < head > < title > Пример страницы </ title > </ head > < body > < p > Привет, мир, это очень простой HTML-документ. </ p > </ body > </ html >Поле заголовка ETag (тег сущности) используется для определения того, идентична ли кэшированная версия запрошенного ресурса текущей версии ресурса на сервере. указывает"Content-Type" тип интернет-носителя данных, передаваемых HTTP-сообщением, а также "Content-Length"указывает его длину в байтах. Веб-сервер HTTP/1.1 публикует свою способность отвечать на запросы для определенных диапазонов байтов документа, устанавливая поле "Accept-Ranges: bytes". Это полезно, если клиенту необходимо иметь только определенные части [62] ресурса, отправленного сервером, что называется обслуживанием байтов . Когда "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 . [63] Существуют также два других метода установления зашифрованного HTTP-соединения: Secure Hypertext Transfer Protocol и использование заголовка HTTP/1.1 Upgrade для указания обновления до TLS. Однако поддержка браузерами этих двух методов практически отсутствует. [64] [65] [66]
Это снижает барьер для развертывания TLS 1.3, что является значительным улучшением безопасности по сравнению с TLS 1.2.
Распространенной ошибкой является использование GET для действия, обновляющего ресурс. [...] Эта проблема привлекла внимание общественности Rails в 2005 году, когда был выпущен Google Web Accelerator.
