Страница защищена ожидающими изменениями
Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

Разработка HTTP была инициирована Тимом Бернерсом-Ли в CERN в 1989 году. Разработка первых HTTP- запросов для комментариев (RFC) была скоординированной работой Инженерной группы Интернета (IETF) и Консорциума World Wide Web (W3C). позже перешел в IETF.

HTTP / 1.1 был впервые задокументирован в RFC  2068 в 1997 году, а по состоянию на 2021 год он (плюс более старые версии) менее популярен (используется менее 45% веб-сайтов; это всегда протокол резервного копирования) для веб-обслуживания, чем его преемники. Эта спецификация была отменена RFC 2616 в 1999 году, который также был заменен семейством RFC RFC 7230 в 2014 году.  

HTTP / 2 является более эффективным выражением семантики HTTP «на проводе», был опубликован в 2015 году и используется более чем на 50% веб-сайтов; теперь он поддерживается практически всеми веб-браузерами [2] и основными веб-серверами через Transport Layer Security (TLS) с использованием расширения Application-Layer Protocol Negotiation (ALPN) [3], где требуется TLS 1.2 или новее. [4] [5]

HTTP / 3 является предлагаемым преемником HTTP / 2, [6] [7], который уже используется более чем 5,8% веб-сайтов; и используется более чем 7,5% настольных компьютеров (по умолчанию включено в последней версии macOS ), используя UDP вместо TCP для основного транспортного протокола. Как и HTTP / 2, он не отменяет предыдущие основные версии протокола. Поддержка HTTP / 3 была добавлена ​​в Cloudflare и Google Chrome в сентябре 2019 года [8] [9] и может быть включена в стабильных версиях Chrome и Firefox. [10]

Технический обзор [ править ]

URL-адрес, начинающийся со схемы HTTP и метки имени домена WWW

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

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

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

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

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

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

История [ править ]

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

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

Первой документированной версией HTTP была HTTP V0.9 (1991). Дэйв Рэггетт возглавил рабочую группу HTTP (HTTP WG) в 1995 году и хотел расширить протокол за счет расширенных операций, расширенного согласования, более богатой метаинформации, связанной с протоколом безопасности, который стал более эффективным за счет добавления дополнительных методов и полей заголовков . [15] [16] RFC 1945 официально представил и признал HTTP V1.0 в 1996 году. 

Рабочая группа HTTP планировала опубликовать новые стандарты в декабре 1995 года [17], и поддержка предварительного стандарта HTTP / 1.1 на основе разрабатываемого тогда RFC 2068 (называемого HTTP-NG) была быстро принята основными разработчиками браузеров в начале 1996 года. Конец -пользователи быстро приняли новые браузеры. В марте 1996 г. одна хостинговая компания сообщила, что более 40% браузеров, используемых в Интернете, были совместимы с HTTP 1.1. Та же самая веб-хостинговая компания сообщила, что к июню 1996 года 65% всех браузеров, обращающихся к их серверам, были совместимы с HTTP / 1.1. [18] Стандарт HTTP / 1.1, как определено в RFC 2068, был официально выпущен в январе 1997 года. Улучшения и обновления стандарта HTTP / 1.1 были выпущены в соответствии с RFC.   2616 в июне 1999 г.

В 2007 году была сформирована рабочая группа HTTP , чтобы частично пересмотреть и уточнить спецификацию HTTP / 1.1. В июне 2014 года WG выпустила обновленную спецификацию из шести частей, отменяющую 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 / 2 был опубликован как RFC 7540 в мае 2015 года. 

HTTP-сеанс [ править ]

HTTP-сеанс - это последовательность сетевых транзакций запрос – ответ. Клиент HTTP инициирует запрос, устанавливая соединение протокола управления передачей (TCP) с определенным портом на сервере (обычно порт 80, иногда порт 8080; см. Список номеров портов TCP и UDP ). HTTP-сервер, прослушивающий этот порт, ожидает сообщения запроса от клиента. После получения запроса сервер отправляет обратно строку состояния, например « HTTP / 1.1 200 OK », и собственное сообщение. Тело этого сообщения обычно является запрошенным ресурсом, хотя также может быть возвращено сообщение об ошибке или другая информация. [1]

Постоянные соединения [ править ]

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

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

Состояние сеанса HTTP [ править ]

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

HTTP-аутентификация [ править ]

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

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

Области аутентификации [ править ]

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

Формат сообщения [ править ]

Клиент отправляет запросы на сервер, а сервер отправляет ответы .

Сообщение-запрос [ редактировать ]

Сообщение-запрос состоит из следующего:

  • строка запроса (например, GET /images/logo.png HTTP / 1.1 , который запрашивает ресурс, вызываемый /images/logo.pngс сервера)
  • поля заголовка запроса (например, Accept-Language: en )
  • пустая строка
  • необязательное тело сообщения

Строка запроса и другие поля заголовка должны заканчиваться на <CR> <LF> (то есть символ возврата каретки, за которым следует символ перевода строки ). Пустая строка должна состоять только из <CR> <LF> и никаких других пробелов . [20] В протоколе HTTP / 1.1 все поля заголовка, кроме Host, являются необязательными.

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

Способы запроса [ править ]

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

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

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

ПОЛУЧАТЬ
Метод GET запрашивает представление указанного ресурса. Запросы, использующие GET, должны только получать данные и не должны иметь никакого другого эффекта. (Это также относится и к некоторым другим методам HTTP.) [1] W3C опубликовал принципы наведения на это различие, говоря, « Веб - приложение дизайн должен быть проинформирован вышеизложенными принципами, но и соответствующими ограничениями.» [27] См. Безопасные методы ниже.
ГОЛОВА
Метод HEAD запрашивает ответ, идентичный таковому для запроса GET, но без тела ответа. Это полезно для получения метаинформации, записанной в заголовках ответов, без необходимости транспортировать весь контент.
ПОЧТОВЫЙ
Метод POST требует, чтобы сервер принял объект, включенный в запрос, как новый подчиненный веб-ресурс, идентифицированный URI. POSTed данные могут быть, например, аннотацией для существующих ресурсов; сообщение для доски объявлений, группы новостей, списка рассылки или ветки комментариев; блок данных, который является результатом отправки веб-формы в процесс обработки данных; или элемент для добавления в базу данных. [28]
ПОЛОЖИТЬ
Метод PUT запрашивает, чтобы закрытый объект был сохранен под предоставленным URI . Если URI относится к уже существующему ресурсу, он изменяется; если URI не указывает на существующий ресурс, то сервер может создать ресурс с этим URI. [29]
УДАЛИТЬ
Метод DELETE удаляет указанный ресурс.
СЛЕД
Метод TRACE повторяет полученный запрос, чтобы клиент мог видеть, какие (если есть) изменения или дополнения были сделаны промежуточными серверами.
ОПЦИИ
Метод OPTIONS возвращает методы HTTP, которые сервер поддерживает для указанного URL . Это можно использовать для проверки функциональности веб-сервера, запросив «*» вместо определенного ресурса.
СОЕДИНЯТЬ
[30] Метод CONNECT преобразует соединение запроса в прозрачный туннель TCP / IP , обычно для облегчениязашифрованной связи SSL (HTTPS) через незашифрованный HTTP-прокси . [31] [32] См. Метод HTTP CONNECT .
ПЛАСТЫРЬ
Метод PATCH применяет частичные изменения к ресурсу. [33]

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

Безопасные методы [ править ]

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

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

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

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

Идемпотентные методы и веб-приложения [ править ]

Методы PUT и DELETE определены как идемпотентные , что означает, что несколько одинаковых запросов должны иметь тот же эффект, что и один запрос. Методы GET, HEAD, OPTIONS и TRACE, прописанные как безопасные, также должны быть идемпотентными, поскольку HTTP - это протокол без сохранения состояния . [1]

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

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

Безопасность [ править ]

Метод TRACE можно использовать как часть класса атак, известных как межсайтовая трассировка ; по этой причине общий совет по безопасности - отключить его в конфигурации сервера. [37] Microsoft IIS поддерживает собственный метод TRACK, который ведет себя аналогичным образом и который также рекомендуется отключить. [37]

Ответное сообщение [ редактировать ]

Ответное сообщение состоит из следующего:

  • строка состояния, которая включает код состояния и сообщение о причине (например, HTTP / 1.1 200 OK , который указывает, что запрос клиента выполнен успешно)
  • поля заголовка ответа (например, Content-Type: text / html )
  • пустая строка
  • необязательное тело сообщения

Строка состояния и другие поля заголовка должны оканчиваться на <CR> <LF>. Пустая строка должна состоять только из <CR> <LF> и никаких других пробелов . [20] Это строгое требование для <CR> <LF> несколько ослаблено в теле сообщения для последовательного использования других системных разрывов строк, таких как <CR> или <LF> отдельно. [38]

Коды состояния [ править ]

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

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

  • Информационная 1XX
  • Успешный 2XX
  • Перенаправление 3XX
  • Ошибка клиента 4XX
  • Ошибка сервера 5XX

Зашифрованные соединения [ править ]

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

Пример сеанса [ править ]

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

Запрос клиента [ править ]

GET  /  HTTP / 1.1 Хост :  www.example.com

За клиентским запросом (состоящим в данном случае из строки запроса и только одного поля заголовка) следует пустая строка, так что запрос заканчивается двойной новой строкой, каждая в форме возврата каретки, за которой следует перевод строки . В поле «Хост» различаются различные 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 Последнее изменение :  среда, 8 января 2003 г., 23:11:55 GMT Сервер :  Apache / 1.3.3.7 (Unix) (Red-Hat / Linux) ETag :  "3f80f-1b6-3e1cb03b " Accept-Ranges :  bytes Connection :  close< html >  < head >  < title > Пример страницы </ title >  </ head >  < body >  < p > Привет, мир, это очень простой HTML-документ. </ p >  </ body > </ html >

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

Большинство строк заголовка необязательны. Если Content-Length отсутствует, длина определяется другими способами. При кодировании с фрагментированной передачей для обозначения конца содержимого используется размер фрагмента 0. Кодирование идентификаторов без Content-Length считывает содержимое, пока сокет не будет закрыт.

Content-Encoding , как Gzip может быть использован для сжатия передаваемых данных.

Подобные протоколы [ править ]

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

См. Также [ править ]

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

Ссылки [ править ]

  1. ^ a b c d Филдинг, Рой Т .; Геттис, Джеймс; Могул, Джеффри С.; Нильсен, Хенрик Фристик; Масинтер, Ларри; Лич, Пол Дж .; Бернерс-Ли, Тим (июнь 1999 г.). Протокол передачи гипертекста - HTTP / 1.1 . IETF . DOI : 10,17487 / RFC2616 . RFC 2616 .
  2. ^ «Могу ли я использовать ... Таблицы поддержки HTML5, CSS3 и т . Д.» . caniuse.com . Проверено 2 июня 2020 .
  3. ^ «Расширение согласования протокола прикладного уровня безопасности транспортного уровня (TLS)» . IETF. Июль 2014 г. RFC 7301 . 
  4. ^ Belshe, M .; Peon, R .; Томсон, М. "Версия 2 протокола передачи гипертекста, Использование функций TLS" . Проверено 10 февраля 2015 .
  5. ^ Бенджамин, Дэвид. «Использование TLS 1.3 с HTTP / 2» . tools.ietf.org . Проверено 2 июня 2020 . Это снижает барьер для развертывания TLS 1.3, что является значительным улучшением безопасности по сравнению с TLS 1.2.
  6. Епископ, Майк (9 июля 2019 г.). «Протокол передачи гипертекста версии 3 (HTTP / 3)» . tools.ietf.org . проект-ietf-quic-http-22 . Проверено 16 августа 2019 .
  7. ^ Cimpanu, Каталин. «HTTP-over-QUIC будет переименован в HTTP / 3 | ZDNet» . ZDNet . Проверено 19 ноября 2018 .
  8. ^ Cimpanu, Каталин (26 сентября 2019). «Cloudflare, Google Chrome и Firefox добавляют поддержку HTTP / 3» . ZDNet . Проверено 27 сентября 2019 года .
  9. ^ «HTTP / 3: прошлое, настоящее и будущее» . Блог Cloudflare . 2019-09-26 . Проверено 30 октября 2019 .
  10. ^ «Firefox Nightly поддерживает HTTP 3 - Общие - Сообщество Cloudflare» . 2019-11-19 . Проверено 23 января 2020 .
  11. ^ «Общая операция» . RFC 2616 . п. 12. сек. 1.4. DOI : 10,17487 / RFC2616 . RFC 2616 .
  12. ^ «Классические HTTP-документы» . W3.org. 1998-05-14 . Проверено 1 августа 2010 .
  13. ^ Бернерс-Ли, Тим. «Протокол передачи гипертекста» . Консорциум World Wide Web . Проверено 31 августа 2010 года .
  14. ^ Тим Бернерс-Ли . «Исходный протокол HTTP по определению 1991 года» . Консорциум World Wide Web . Проверено 24 июля 2010 года .
  15. ^ Рэггетт, Дэйв. "Биография Дэйва Рэггетта" . Консорциум World Wide Web . Проверено 11 июня 2010 года .
  16. ^ Рэггетт, Дэйв; Бернерс-Ли, Тим. «Рабочая группа по протоколу передачи гипертекста» . Консорциум World Wide Web . Проверено 29 сентября 2010 года .
  17. ^ Рэггетт, Дэйв. «Планы HTTP WG» . Консорциум World Wide Web . Проверено 29 сентября 2010 года .
  18. ^ «HTTP / 1.1» . Webcom.com Глоссарий . Архивировано из оригинала на 2001-11-21 . Проверено 29 мая 2009 .
  19. ^ a b Филдинг, Рой Т .; Решке, Джулиан Ф. (июнь 2014 г.). Протокол передачи гипертекста (HTTP / 1.1): аутентификация . IETF. DOI : 10,17487 / RFC7235 . RFC 7235 .
  20. ^ a b «HTTP-сообщение» . RFC 2616 . п. 31. сек. 4. DOI : 10,17487 / RFC2616 . RFC 2616 .
  21. ^ «Неделя Apache. HTTP / 1.1» . 090502 apacheweek.com
  22. ^ Бернерс-Ли, Тим; Филдинг, Рой Т .; Нильсен, Хенрик Фристик. «Определения методов» . Протокол передачи гипертекста - HTTP / 1.0 . IETF. С. 30–32. сек. 8. дои : 10,17487 / RFC1945 . RFC 1945 .
  23. ^ «Определения методов» . RFC 2616 . С. 51–57. сек. 9. дои : 10,17487 / RFC2616 . RFC 2616 .
  24. ^ "RFC-7210 раздел 3.1.1" . Tools.ietf.org . Проверено 26 июня 2019 .
  25. ^ "RFC-7231 раздел 4.1" . Tools.ietf.org . Проверено 26 июня 2019 .
  26. ^ "RFC-7230 раздел 3.2" . Tools.ietf.org . Проверено 26 июня 2019 .
  27. ^ Джейкобс, Ян (2004). «URI, адресуемость и использование HTTP GET и POST» . Находки группы технической архитектуры . W3C . Проверено 26 сентября 2010 года .
  28. ^ "ПОЧТА" . RFC 2616 . п. 54. сек. 9.5. DOI : 10,17487 / RFC2616 . RFC 2616 .
  29. ^ "ПОЛОЖИТЬ" . RFC 2616 . п. 55. сек. 9.6. DOI : 10,17487 / RFC2616 . RFC 2616 .
  30. ^ "ПОДКЛЮЧИТЬ" . Протокол передачи гипертекста - HTTP / 1.1 . IETF. Июнь 1999. с. 57. сек. 9.9. DOI : 10,17487 / RFC2616 . RFC 2616 . Проверено 23 февраля 2014 года .
  31. ^ Khare, Рохит; Лоуренс, Скотт (май 2000 г.). Обновление до TLS в HTTP / 1.1 . IETF. DOI : 10,17487 / RFC2817 . RFC 2817 .
  32. ^ «Примечание об уязвимости VU # 150227: конфигурации HTTP-прокси по умолчанию разрешают произвольные TCP-соединения» . US-CERT . 2002-05-17 . Проверено 10 мая 2007 .
  33. ^ Дюссо, Лиза; Снелл, Джеймс М. (март 2010 г.). Метод PATCH для HTTP . IETF. DOI : 10,17487 / RFC5789 . RFC 5789 .
  34. ^ «Метод» . RFC 2616 . п. 36. сек. 5.1.1. DOI : 10,17487 / RFC2616 . RFC 2616 .
  35. ^ a b Эдигер, Брэд (21 декабря 2007 г.). Advanced Rails: создание промышленных веб-приложений в рекордно короткие сроки . O'Reilly Media, Inc. стр. 188. ISBN 978-0596519728. Распространенной ошибкой является использование GET для действия, обновляющего ресурс. [...] Эта проблема привлекла внимание общественности Rails в 2005 году, когда был выпущен Google Web Accelerator.
  36. ^ Кантрелл, Кристиан (2005-06-01). "Что мы узнали от Google Web Accelerator?" . Блоги Adobe . Adobe. Архивировано из оригинала на 2017-08-19 . Проверено 19 ноября 2018 .
  37. ^ a b «Межсайтовая трассировка» . OWASP . Проверено 22 июня 2016 .
  38. ^ «Канонизация и текстовые значения по умолчанию» . RFC 2616 . сек. 3.7.1. DOI : 10,17487 / RFC2616 . RFC 2616 .
  39. ^ «Строка состояния» . RFC 2616 . п. 39. сек. 6.1. DOI : 10,17487 / RFC2616 . RFC 2616 .
  40. ^ Канаван, Джон (2001). Основы сетевой безопасности . Норвуд, Массачусетс: Artech House. С. 82–83. ISBN 9781580531764.
  41. ^ Залевски, Михал. «Руководство по безопасности браузера» . Проверено 30 апреля 2015 года .
  42. ^ «Chromium Issue 4527: реализация RFC 2817: обновление до TLS в HTTP / 1.1» . Проверено 30 апреля 2015 года .
  43. ^ «Ошибка Mozilla 276813 - [RFE] Поддержка обновления RFC 2817 / TLS для HTTP 1.1» . Проверено 30 апреля 2015 года .
  44. ^ Луотонен, Ари; Франкс, Джон (22 февраля 1996 г.). Расширение извлечения байтового диапазона для HTTP . IETF. Идентификатор draft-ietf-http-range-retrieval-00.
  45. ^ Ноттингем, Марк (октябрь 2010 г.). Веб-ссылки . IETF. DOI : 10,17487 / RFC5988 . RFC 5988 .
  46. ^ "Протокол передачи гипертекста Bis (httpbis) - Устав" . IETF. 2012 г.


Внешние ссылки [ править ]

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