Обзор протокола http

Форматы сообщений запроса/ответа

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

Давайте посмотрим на структуру передаваемого сообщения через HTTP:

message = <start-line>
          *(<message-header>)
          CRLF
          

<start-line> = Request-Line | Status-Line
<message-header> = Field-Name ':' Field-Value

Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:

Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.

Общие заголовки

Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:

general-header = Cache-Control
               | Connection
               | Date
               | Pragma
               | Trailer
               | Transfer-Encoding
               | Upgrade
               | Via
               | Warning

Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.

Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.

Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache — это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.

Заголовок Date используется для хранения даты и времени запроса/ответа.

Заголовок Upgrade используется для изменения протокола.

Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.

Заголовки сущностей

В заголовках сущностей передаётся мета-информация контента:

entity-header  = Allow
               | Content-Encoding
               | Content-Language
               | Content-Length
               | Content-Location
               | Content-MD5
               | Content-Range
               | Content-Type
               | Expires
               | Last-Modified

Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.

Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.

С помощью данных заголовков, можно задать нужную для ваших задач информацию.

Идентификация и аутентификация

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

Существует несколько мер, при помощи которых сервер извлекает эту информацию, и большинство веб-сайтов используют гибридные методы:

• Заголовки запросов: From, Referer, User-Agent – их мы уже рассмотрели в части 1
• Client-IP — IP адрес клиента,
• Fat Urls — Сохранение состояния текущего пользователя, изменив URL и перенаправив на другой URL после каждого клика; каждый клик, по сути, накапливает состояние,
• Cookies — самый популярный и ненавязчивый подход.

Cookies позволяют серверу передавать обязательную информацию для исходящих сообщений с помощью заголовка ответа Set-Cookie. Cookie устанавливается с одной или более парой имя=значение, разделенных точкой с запятой (;), например: Set-Cookie: session-id=12345ABC; username=nettuts.

Сервер также может ограничить Cookie для конкретного домена или его части (domain и path),что делает их стойкими (неизменными) к истекающим значениям (expires). Cookies автоматически отсылаются браузером при каждом запросе к серверу, и браузер гарантирует, что в запросе отправлены только специальные domain- и path- cookies-сы. Заголовок запроса Cookie: name=value используется для отправки этих cookies на сервер.

“Лучший способ определить пользователя — попросить зарегистрироваться на сайте, но чтобы это реализовать потребуются усилия как со стороны разработчика, так и со стороны пользователя.”

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

Отличия http 1.1 и http/2

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

Еще одно отличие http 2.0 от версии 1.1 – мультиплексирование запросов и ответов
для решения проблемы блокировки начала строки, присущей HTTP 1.1. Еще в новом протоколе можно сжимать
HTTP заголовки
и вводить приоритеты для запросов.

Обслуживание соединения со стороны сервера

В основном сервер прослушивает входящие сообщения и обрабатывает их по мере поступления запросов. Операции сервера включают в себя:

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

прерывание соединение, если возникло сообщение: Connection: close.

Естественно, это далеко не полный перечень операций. Для создания наиболее индивидуальных ответов веб-сайты и программы должны “понимать”, кто посылает запросы. За это отвечают процессы идентификации и аутентификации.

Что важно понимать про HTTP

1. HTTP — это протокол общения клиент-серверных приложений в вебе. Набор правил, который помогает клиентам (прежде всего браузерам) и веб-серверам понимать друг друга.
2. HTTP — это про формат общения, а не про управление сервером HTTP-командами. Клиент может отправить что угодно: удали страницу сайта, создай нового пользователя, выдай список всех пользователей — но сервер не обязан их выполнять, он лишь обязан ответить в формате HTTP, чтобы клиент его понял. То есть благодаря HTTP сервер поймёт, что клиент хочет, а потом уже решит, как это обработать и вернёт результат. Может быть удалит страницу, а может и нет.
3. В HTTP общение всегда начинает клиент. А веб-сервер висит и ждёт. Сейчас есть способы инициировать запрос с сервера, но изначально протокол для этого не предназначен.
4. HTTP-протокол не имеет шифрования, поэтому передавать персональные данные и прочие приватные данные через него не безопасно. В таком случае нужно использовать HTTPS.
5. Простой способ изучить заголовки запроса и ответа — открыть консоль браузера на нужной странице и обновить её. В разделе Network/Сеть отобразятся все запросы с этой страницы, включая запросы на картинки и статические файлы.

HTTP-ответы

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

В качестве версии HTTP указывается та версия, которую сервер использует в ответе. Код состояния представляет собой трехбайтовое число, указывающее результат обработки сервером запроса клиента. Описание, следующее за кодом состояния, просто дает удобное для восприятия пользователем значение кода состояния. Хотя существует несколько определенных кодов состояния, сервер вправе устанавливать дополнительные коды. Некоторые наиболее распространенные определенные коды приводятся в следующей таблице:

После строки состояния сервер отправляет клиенту в заголовках информацию о себе и запрошенном документе. Заголовки завершаются пустой строкой (т.е. двумя идущими подряд последовательностями CRLF).

Если клиент запрашивал данные и запрос обработан успешно, эти данные будут отправлены в теле сущности после заголовков ответа. Они могут представлять собой копию запрошенного файла или содержание, сгенерированное динамически, например страницу ASP.NET или сценарий на стороне сервера. Если запрос клиента не выполнен, могут быть предоставлены дополнительные данные объясняющие, почему сервер не смог выполнить этот запрос.

В HTTP 1.0 сервер, завершив отправку запрошенных данных, отсоединяется от клиента и транзакция на этом заканчивается, если только не был отправлен заголовок Connection: Keep-Alive. Однако в HTTP 1.1 сервер должен поддерживать соединение, позволяя клиенту делать дополнительные запросы, даже если заголовок Connection не был отправлен. Если не нужно такое поведение, следует отправить заголовок Connection: close, который указывает, что после отправки ответа соединение должно быть закрыто.

HTTP-СОЕДИНЕНИЕ

Соединение между клиентом и сервером устанавливается обязательно до того, как они смогут “общаться” друг с другом, при этом используется самый надежный протокол-TCP. По умолчанию, TCP использует 80-ый порт. Поток разбивается на пакеты IP,что гарантирует получение пакетов в правильном порядке без потерь. HTTP-протокол прикладного уровня TCP, основанного на IP. HTTPS — защищенная версия HTTP, куда вставлены дополнительные уровни между HTTP и TCP, называемые TLS и SSL (Transport Layer Security и Secure Sockets Layer, соответственно). По умолчанию, HTTPS использует 443-ий TCP-порт, и в данной статье будет рассмотрен именно HTTPS- протокол.

Подключение HTTP идентифицируется как <исходный IP, исходный порт> и <IP приемника, порт приемника>. На клиентском уровне протокол представлен кортежем: <IP, порт>. Установка соединения между двумя конечными точками — процесс многоступенчатый. Он включает в себя следующие шаги:

• расчет IP адреса по имени хоста DNS,
• установление соединения с сервером,
• отправка запроса,
• ожидание ответа,
• закрытие соединения.

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

Чтобы избавиться от этих задержек, в HTTP/1.1 были введены постоянные соединения — долгоживущие соединения, которые остаются открытыми, пока клиент не закроет их. Эти соединения используются по умолчанию, а чтобы произвести транзакцию клиент должен установить соединение: “Connection: close” в заголовке запроса. Это значит, что сервер должен прервать соединение сразу после того, как оправит ответ клиенту.

Помимо постоянных соединений, браузеры / клиенты для минимизации времени задержек сети используют метод, называемый параллельные соединения. Старая концепция параллельных соединений заключается в создании пула соединений (как правило, не более шести соединений). То есть, если клиент хочет загрузить с веб-сайта шесть ресурсов, создаются шесть параллельных соединений, в результате чего время отклика становится минимальным. Это огромный плюс по сравнению с последовательными соединениями, где клиент скачивает ресурсы друг за другом.

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

Постоянное соединение в HTTP

Альтернативный подход, который называется постоянное соединение, заключается в том что можно один раз установить соединение tcp и затем использовать его для загрузки различных ресурсов не только HTML страницы, но и стилевых файлов, javascript, картинок и всех связанных ресурсов. TCP соединения разрываются после того, как все ресурсы были загружены.

По-английски постоянное соединение называется HTTP persistent connection или HTTP keep-alive. Использование постоянного соединения позволяет повысить скорость загрузки web-страниц.

1. Во-первых, нет необходимости каждый раз устанавливать HTTP соединения, то есть мы не проходим процедуру трехкратного рукопожатия.
2. Во вторых, скорость передачи данных при установке нового соединения TCP низкая. Для того чтобы регулировать скорость передачи данных, TCP используют размер окна, чем больше размер окна тем больше скорость передачи данных. Так как при установке соединения, TCP ничего не знает про сеть, то используется маленький размер окна, который увеличивается при получении каждого подтверждения с помощью механизма slowstart, а затем аддитивного увеличения мультипликативного уменьшения. Если мы не открываем каждый раз новое соединение, а используем существующие, то нам не надо каждый раз начинать с маленького размера окна, и мы используем существующее TCP соединение, которое позволяет передавать данные на высокой скорости.

Ошибка 403 Forbidden

Код состояния 403, или ошибка Forbidden («запрещено») значит, что запрос пользователя был отправлен верно, но сервер отказывается обслуживать его в связи с отсутствием разрешения на доступ к запрашиваемому ресурсу. В этом разделе описаны наиболее распространенные причины возникновения ошибки 403.

Права на файл

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

Чтобы привести пример устранения ошибки 403, предположим, что:

• пользователь пытается получить доступ к индексному файлу (http://example.com/index.html);
• рабочий процесс веб-сервера принадлежит пользователю www-data;
• индексный файл на сервере находится в /usr/share/nginx/html/index.html.

Итак, если пользователь получает ошибку 403 Forbidden, убедитесь, что пользователь www-data имеет права на чтение файла. Как правило, в подобной ситуации нужно просто изменить права на файл. Это можно сделать несколькими способами, но в данном случае подойдет вот эта команда:

sudo chmod o=r /usr/share/nginx/html/index.html

Файл .htaccess

Еще одна потенциальная причина возникновения ошибки 403 (часто это делается намеренно) – использование файла .htaccess. При помощи файла .htaccess можно запретить конкретным IP-адресам (или диапазонам адресов) доступ к определенным ресурсам.

Если пользователи неожиданно получают ошибку 403 Forbidden, убедитесь, что она не была вызвана настройками файла .htaccess.

Несуществующий индексный файл

Если пользователь пытается получить доступ к каталогу, который не имеет стандартного индексного файла, а листинг каталога (directory listing) отключен, веб-сервер будет возвращать ошибку 403 Forbidden. Такое случится, если, например, пользователь попытается получить доступ к каталогу http://example.com/emptydir/, а в каталоге emptydir на сервере нет индексного файла. Листинг каталога можно включить в конфигурациях сервера.

Библиотеки для работы с HTTP — jQuery AJAX

Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте.

Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().

$.ajax({
    url: 'http://www.articles.com/latest',
    type: 'GET',
    beforeSend: function (jqXHR) {
      jqXHR.setRequestHeader('Accepts-Language', 'en-US,en');
    }
  });

Прочитать объект jqXHR можно с помощью метода jqXHR.getResponseHeader().

Если хотите обработать статус запроса, то это можно сделать так:

$.ajax({
  statusCode: {
    404: function() {
      alert("page not found");
    }
  }
});

5 последних уроков рубрики «Разное»

• Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.

• Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов

  Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.

• Создание вебсайта — процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.

• Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.

Функциональность

Механизм и концепция HTTP включает в себя то, что файлы связаны с другими файлами через ряд ссылок. Этот выбор вызовет дополнительные запросы на передачу. Любое устройство веб-сервера на самом деле содержит программу, которая называется HTTP-демоном, которая предназначена для прогнозирования HTTP-запросов и обработки их по их получении. Типичный веб-браузер — это HTTP-клиент, который постоянно посылает запросы на серверные устройства. Пользователь вводит запросы в файл, проходя через веб-файл, который в данном случае обычно является URL-адресом, или нажимает на ссылку; браузер формирует HTTP-запрос, а затем отправляет его на IP-адрес, указанный через URL.

HTTP следует заданному циклу всякий раз, когда посылает запрос:

1. Браузер запросит HTML-страницу. Затем сервер возвращает HTML-файл с хоста.1
2. Браузер запросит таблицу стилей. Затем сервер возвращает файл CSS.
3. Браузер запрашивает изображение в формате JPG. Сервер возвращает файл JPG.
4. Браузер запросит код JavaScript (язык программирования). После этого сервер возвращает JS-файл.
5. Браузер запрашивает различные формы данных. Сервер возвращает данные в виде XML или JSON файлов.

2017

Россия: число сайтов с SSL-сертификатами за год выросло в четыре раза

По данным аналитического сервиса StatOnline, в российских национальных доменных зонах количество сайтов, использующих SSL-сертификаты, за год выросло в четыре раза. В июле 2015 года в зоне .RU количество таких ресурсов составляло 109 тыс., в том же месяце 2016 года — 189 тыс., а в июле 2017 года — 531 тыс. Для сравнения, показатели зоны .РФ составляли 18 тыс., 21 тыс. и 65 тыс. соответственно. По состоянию на август 2017 года, всего в зоне .RU насчитывается 5,5 млн сайтов, в зоне.РФ — 900 тыс., передают «Известия».

HTTPS-протокол призван защитить данные пользователей от перехвата. Согласно обещаниям , ссылки на ресурсы, которые всё еще не перешли на HTTPS, с начала 2018 года будут отображаться в результатах поиска с предупреждением об их небезопасности. С похожей инициативой выступила и компания Mozilla, выпускающая браузер Firefox.

SSL-сертификаты — уникальная цифровая подпись сайта, необходимая для организации защищенного соединения между браузером интернет-пользователя и сервером. Обычные сайты используют для обмена данными протокол HTTP, ресурсы с сертификатом — защищенный HTTPS. SSL-сертификаты выпускаются на разные сроки. По данным StatOnline, наиболее распространенный период действия SSL-сертификата — менее 1 года. В зоне .RU число таких сертификатов составляет 82% от общего числа, а в зоне .РФ — 95%.

Антивирусы влияют на безопасность HTTPS

13 февраля 2017 года группа исследователей опубликовала отчет о влиянии антивирусного ПО на безопасность HTTPS-трафика, в котором подтвердились предположения экспертов о небезопасном влиянии антивирусных средств на зашифрованный трафик.

В составе группы действовали специалисты Mozilla, , CloudFlare, представители университета Мичигана, иллинойсского университета в Урбан-Шампейне, калифорнийского университета в Беркли и Международного института информатики.

Эксперты подозревали о влиянии инструментов защиты на защищенные соединения, в результате чего зашифрованный трафик подвергается риску и безопасность ослабевает. Они оказались правы в своих подозрениях.
Исследователи проанализировали подтверждения сессий связи (handshakes), связанных с браузерами, антивирусными продуктами и вредоносными программами, и на основе этого создали эвристические методы контроля перехвата и вмешательства в HTTPS, определения субъекта перехвата трафика.

Созданные для тестов инструменты разместили на серверах Mozilla Firefox, CloudFlare CDN и сайтах электронной коммерции. Анализ показал: 4% соединений Firefox, 6,2% соединений e-commerce сайтов и 11% соединений CloudFlare перехвачены. После чего большинство этих соединений стали менее безопасны (97% применительно к Firefox, 54% для CloudFlare и 32% для e-commerce ресурсов). Безопасность более 62% процентов соединений ослабла до относительно приемлемого уровня, а 58% соединений стали подвержены критическим уязвимостям.

По мнению экспертов, беспокойство вызывает не только то, что перехватчики соединений использовали более слабые криптографические алгоритмы, но и то, что 10-40% из них объявили о поддержке давно взломанных шифров, что позволяет атакующему в позиции Man in the middle (MITM) перехватить соединение, произвести downgrade и расшифровать его.

Исследователи изучили работу продуктов A10 Networks, Blue Coat, Barracuda, Check Point, Cisco, Forcepoint, Fortinet, Juniper Networks, Microsoft, Sophos, Untangle и WebTitan. Из этого списка только технологии Blue Coat, по мнению исследователей, обращались с TLS-соединениями корректно. Остальные продукты получили 2-3 балла по пятибалльной шкале из-за уязвимостей и потенциальных MitM-атак.

Таблица оценки влияния антивирусных систем на трафик HTTPS, (2017)

Несколько слов о наступающем будущем — HTTP/2

Первая версия протокола HTTP была принята 20 лет назад. После этого 10 лет была тишина, пока Google не стал разрабатывать свой протокол SPDY поверх HTTP, что дало ускорение работе над HTTP/2. После серёзных подвижек Google отказался от разработки SPDY в пользу HTTP/2.

Вторая версия протокола отличается от первой чуть меньше, чем полностью.

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

Новый протокол безопаснее и в несколько раз быстрее. Самое приятное, что последние версии современных браузеров понимают http2, и половина наиболее крупных и популярных сайтов уже готовы к переходу на него. С приходом http2 веб станет ещё более интерактивным, а приложения приблизятся к десктопным.

HTTP поток

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

1. Открытие TCP соединения: TCP-соединение будет использоваться для отправки запроса (или запросов) и получения ответа. Клиент может открыть новое соединение, переиспользовать существующее или открыть несколько TCP-соединений к серверу.
2. Отправка HTTP-сообщения: HTTP-сообщения (до HTTP/2) являются человекочитаемыми. Начиная с HTTP/2, простые сообщения инкапсулируются во фреймы, делая невозможным их чтение напрямую, но принципиально остаются такими же.
3. Читает ответ от сервера:
4. Закрывает или переиспользует соединение для дальнейших запросов.

Если активирован HTTP-конвейер, несколько запросов могут быть отправлены без ожидания получения первого ответа целиком. HTTP-конвейер тяжело внедряется в существующие сети, где старые куски ПО сосуществуют с современными версиями. HTTP-конвейер был заменён в HTTP/2 на более надёжные мультиплексные запросы во фрейме.

Постоянное соединение в HTTP 1.0

В стандарте HTTP  1.0 не было возможности использовать постоянное соединение. Уже после публикации стандарта был придуман специальный заголовок Connection: keep-alive. Клиент добавляет этот заголовок к запросу, для того чтобы попросить сервер не закрывать соединение после передачи ответа. Если сервер понимает этот заголовок и поддерживает постоянное соединение, он оставляет соединение открытым и добавляет этот заголовок к ответу.

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

Рассмотрим пример использования заголовка

Посылаем запрос http, используя метод GET, хотим получить страничку со статьями по протоколам (/tehnologii/protokoli), которые находятся на сайте (www.zvondozvon.ru) по протоколу HTTP/1.0.

Добавляем заголовок Connection:keep-alive для того чтобы попросить сервер не разрывать соединение после того как он передаст нам web-страницу.

Сервер присылает нам ответ

Первая строчка статус 200 ОК, означает, что необходимая нам страница найдена. Дальше идут заголовки, и нужный нам заголовок Connection:keep-alive, который говорит о том, что сервер поддерживает постоянное соединение и он оставил соединение открытым для того чтобы можно было загружать следующие ресурсы.

История

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

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

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

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

В 2007 г. был создан, в частности, для пересмотра и уточнения спецификации HTTP / 1.1. В июне 2014 года WG выпустила обновленную спецификацию из шести частей, устаревающую. RFC :

• RFC , HTTP / 1.1: синтаксис сообщений и маршрутизация
• RFC , HTTP / 1.1: семантика и контент
• RFC , HTTP / 1.1: условные запросы
• RFC , HTTP / 1.1: запросы диапазона
• RFC , HTTP / 1.1: кеширование
• RFC , HTTP / 1.1: аутентификация

HTTP / 2 был опубликован как RFC  в мае 2015 года.