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]его используют 36% веб-сайтов [7] и поддерживают почти все веб-браузеры (более 98% пользователей). [8] Он также поддерживается основными веб-серверами через Transport Layer Security (TLS) с использованием расширения Application-Layer Protocol Negotiation (ALPN) [9] , где требуется TLS 1.2 или новее. [10] [11]
HTTP/3 , преемник HTTP/2, был опубликован в 2022 году. [12] По состоянию на февраль 2024 года [update]он сейчас используется на 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 , чтобы сформировать взаимосвязанные гипертекстовые документы.
В HTTP/1.0 для каждого запроса ресурса устанавливается отдельное TCP- соединение с одним и тем же сервером. [20]
Вместо этого в HTTP/1.1 TCP-соединение можно повторно использовать для выполнения нескольких запросов ресурсов (например, HTML-страниц, фреймов, изображений, сценариев , таблиц стилей и т. д.). [21] [22]
Таким образом, связь HTTP/1.1 имеет меньшую задержку, поскольку установление TCP-соединений сопряжено со значительными накладными расходами, особенно в условиях высокого трафика. [23]
HTTP/2 — это версия предыдущего HTTP/1.1, позволяющая сохранить ту же модель клиент-сервер и те же методы протокола, но со следующими отличиями по порядку:
Таким образом, связь 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/0.9 не поддерживал поля заголовка в запросе, в нем не существует механизма поддержки виртуальных хостов на основе имени (выбор ресурса путем проверки поля заголовка Host). Любой сервер, реализующий виртуальные хосты на основе имен, должен отключить поддержку HTTP/0.9 . Большинство запросов, которые кажутся HTTP/0.9, на самом деле являются плохо построенными запросами HTTP/1.x, вызванными тем, что клиент не может правильно закодировать цель запроса.
HTTP — это протокол уровня приложения без отслеживания состояния , и для обмена данными между клиентом и сервером ему требуется надежное сетевое транспортное соединение. [19] В реализациях HTTP соединения TCP/IP используются с использованием хорошо известных портов (обычно порт 80 , если соединение не зашифровано, или порт 443, если соединение зашифровано, см. также Список номеров портов TCP и UDP ). [43] [44] В HTTP/2 используется соединение TCP/IP плюс несколько каналов протокола. В HTTP/3 используется транспортный протокол приложений QUIC через UDP.
Обмен данными осуществляется через последовательность сообщений запрос-ответ , которыми обмениваются транспортные соединения сеансового уровня . [19] HTTP-клиент сначала пытается подключиться к серверу, устанавливающему соединение (реальное или виртуальное). Сервер HTTP(S), прослушивающий этот порт, принимает соединение, а затем ожидает сообщения запроса от клиента. Клиент отправляет сообщение HTTP-запроса. После получения запроса сервер отправляет ответное сообщение HTTP, которое включает в себя заголовок(и) плюс тело, если оно необходимо. Тело этого ответного сообщения обычно представляет собой запрошенный ресурс, хотя также может быть возвращено сообщение об ошибке или другая информация. В любой момент (по многим причинам) клиент или сервер может закрыть соединение. Закрытие соединения обычно объявляется заранее с использованием одного или нескольких заголовков HTTP в последнем сообщении запроса/ответа, отправленном на сервер или клиент. [21]
В 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 (см. также: технический обзор).
"Content-Length: number"
не присутствовал в заголовках HTTP, и клиент предполагал, что, когда сервер закрыл соединение, содержимое было отправили целиком. Этот механизм не мог отличить успешно завершенную передачу ресурса от прерванной (из-за ошибки сервера/сети или чего-то еще).HTTP предоставляет несколько схем аутентификации, таких как базовая аутентификация доступа и дайджест-аутентификация доступа , которые работают через механизм запроса-ответа, при котором сервер идентифицирует и отправляет запрос перед обслуживанием запрошенного контента.
HTTP обеспечивает общую структуру для управления доступом и аутентификации посредством расширяемого набора схем аутентификации запрос-ответ, которые могут использоваться сервером для запроса запроса клиента и клиентом для предоставления информации аутентификации. [1]
Описанные выше механизмы аутентификации относятся к протоколу HTTP и управляются клиентским и серверным программным обеспечением HTTP (если оно настроено на требование аутентификации перед предоставлением клиенту доступа к одному или нескольким веб-ресурсам), а не веб-приложениями, использующими сеанс веб-приложения.
Спецификация HTTP-аутентификации также предоставляет произвольную, зависящую от реализации конструкцию для дальнейшего разделения ресурсов, общих для данного корневого URI . Строка значения области, если она присутствует, объединяется с каноническим корневым URI для формирования компонента защитного пространства задачи. Фактически это позволяет серверу определять отдельные области аутентификации под одним корневым URI. [1]
HTTP — протокол без сохранения состояния . Протокол без сохранения состояния не требует, чтобы веб-сервер сохранял информацию или статус каждого пользователя на протяжении нескольких запросов.
Некоторым веб-приложениям необходимо управлять сеансами пользователей, поэтому они реализуют состояния или сеансы на стороне сервера , используя, например, файлы cookie HTTP [45] или скрытые переменные в веб-формах .
Чтобы начать сеанс пользователя приложения, необходимо выполнить интерактивную аутентификацию через вход в веб-приложение. Чтобы остановить сеанс пользователя, пользователь должен запросить операцию выхода из системы . В операциях такого типа используется не HTTP-аутентификация, а настраиваемая управляемая аутентификация веб-приложения.
Сообщения запроса отправляются клиентом на целевой сервер. [примечание 4]
Клиент отправляет серверу сообщения запроса , которые состоят из: [46]
ПОЛУЧИТЬ /images/logo.png HTTP / 1.1
Хост: www.example.comПринять-Язык: ru
В протоколе HTTP/1.1 все поля заголовка, кроме поля, Host: hostname
являются необязательными.
Строка запроса, содержащая только имя пути, принимается серверами для обеспечения совместимости с HTTP-клиентами до спецификации HTTP/1.0 в RFC 1945. [47]
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]
Content-Length
.Все веб-серверы общего назначения должны реализовывать как минимум методы GET и HEAD, а все остальные методы согласно спецификации считаются необязательными. [51]
Метод запроса безопасен, если запрос с использованием этого метода не оказывает ожидаемого воздействия на сервер. Методы 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 не кэшируются.
Поля заголовка запроса позволяют клиенту передавать дополнительную информацию за пределы строки запроса, действуя как модификаторы запроса (аналогично параметрам процедуры). Они предоставляют информацию о клиенте, о целевом ресурсе или об ожидаемой обработке запроса.
Ответное сообщение отправляется сервером клиенту в качестве ответа на его предыдущее сообщение запроса. [примечание 4]
Сервер отправляет клиенту ответные сообщения , которые состоят из: [46]
HTTP / 1.1 200 ОК
Тип контента: текст/html
В HTTP/1.0 и последующих версиях первая строка ответа HTTP называется строкой состояния и включает в себя числовой код состояния (например, « 404 ») и текстовую фразу причины (например, «Не найден»). Код состояния ответа представляет собой трехзначный целочисленный код, представляющий результат попытки сервера понять и удовлетворить соответствующий запрос клиента. То, как клиент обрабатывает ответ, зависит в первую очередь от кода состояния и, во вторую очередь, от других полей заголовка ответа. Клиенты могут не понимать все зарегистрированные коды состояния, но они должны понимать свой класс (задаваемый первой цифрой кода состояния) и рассматривать нераспознанный код состояния как эквивалент кода состояния 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 Пользовательский агент : Mozilla/5.0 Принять : text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/* ;q=0.8 Accept-Language : en-GB,en;q=0.5 Accept-Encoding : gzip, deflate, br Соединение : keep-alive
За клиентским запросом (состоящим в данном случае из строки запроса и нескольких заголовков, которые можно свести к одному "Host: hostname"
заголовку) следует пустая строка, так что запрос заканчивается двойным концом строки, каждый из которых имеет форму возврат каретки с последующим переводом строки . Значение "Host: hostname"
заголовка различает различные DNS- имена, использующие один IP-адрес , что позволяет осуществлять виртуальный хостинг на основе имен . Хотя это необязательно в HTTP/1.0, оно является обязательным в HTTP/1.1. (Кошка «/» (косая черта) обычно означает файл /index.html , если он есть.)
HTTP / 1.1 200 OK Дата : понедельник, 23 мая 2005 г., 22:38:34 GMT Тип контента : 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 : байты 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"
. Это полезно, если клиенту необходимо иметь только определенные части [61] ресурса, отправленного сервером, что называется обслуживанием байтов . Когда "Connection: close"
отправляется, это означает, что веб-сервер закроет TCP -соединение сразу после окончания передачи этого ответа. [21]
Большинство строк заголовка не являются обязательными, но некоторые являются обязательными. Если в ответе с телом объекта отсутствует заголовок "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 . [62] Также существуют два других метода установки зашифрованного HTTP-соединения: протокол безопасной передачи гипертекста и использование заголовка обновления HTTP/1.1 для указания обновления до TLS. Однако поддержка этих двух браузеров практически отсутствует. [63] [64] [65]
Это снижает барьер для развертывания TLS 1.3, что является значительным улучшением безопасности по сравнению с TLS 1.2.
Распространенной ошибкой является использование GET для действия по обновлению ресурса. [...] Эта проблема привлекла внимание общественности Rails в 2005 году, когда был выпущен Google Web Accelerator.