Протокол http: обзор для чайников

Кодирование данных в формат base64

Base64 относится к группе транспортных кодировок, и позволяет представлять бинарные данные в виде ASCII строк, переводя их в radix-64 представление. Состоя только из ASCII символов, base64 строки являются допустимыми для использования в URL, по этой причине они могут быть использованы и в Data URL.

Web API имеет встроенные методы для кодирования и декодирования формата base64: Base64 кодирование и декодирование.

На Linux и Mac OS X системах, кодирование файлов или строк в формат Base64 может быть выполнено через программу в командной строке (или, в качестве альтернативы, программу с аргументом).

Кодирование на Windows может быть выполнено через powershell или какую-либо другую предназначенную для этого программу. Так же кодирование может быть выполнено и через программу (смотрите секцию Кодирование на Unix системах), при условии активированной технологии WSL.

::ToBase64String(::UTF8.GetBytes("hello"))
# выводит в консоль: aGVsbG8=

bash -c "echo -n hello`|base64"
# выводит в консоль: aGVsbG8=
# обратный апостроф (`) используется здесь для экранирования символа вертикальной черты (|)

HTTPS – что это

Модуль http в python

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

HTTP и HTTPS всегда можно видеть в начале ссылок. Сама модель ссылки подразумевает, что в самом начале всегда указывается протокол передачи данных. Если вы введете http, сайт откроется по этому протоколу. Если https, браузер попытается открыть его по защищенному каналу, однако это не всегда сработает.

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

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

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

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

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

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

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

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

Web прокси сервер (proxy server)

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

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

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

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

Распространённые проблемы

Протоколы vpn: какой протокол лучше и в чем состоят различия между ними

Эта секция описывает ряд проблем, которые могут возникнуть при использовании Data URL.

Для примера рассмотрим Data URL вида:

data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val

результатом декодирования которого будет HTML строка:

lots of text...<p><a name="bottom">bottom</a>?arg=val

Синтаксис: Data URL представляет собой простой формат, но даже в нём можно забыть добавить запятую перед сегментом данных или произвести ошибку во время их base64 кодирования.
Форматирование внутри документа: Встраивание Data URL по сути является встраиванием файла внутрь файла, и длина его строки может быть намного шире, чем ширина заключающего его документа. Так же, несмотря на то, что использование пробелов считается обычной практикой при форматировании данных, есть вероятность, что у вас возникнут проблемы .
Ограничения длины: Хотя Firefox поддерживает Data URL практически неограниченных размеров, каждый отдельный браузер имеет свои ограничения на их длину. Например, Opera 11 ограничивает допустимую длину URL до 65535 символов, что означает ограничение сегмента данных в Data URL до 65529 символов (длина в 65529 символов взята из условия использования только только сегмента, без определения MIME типа данных).
Нехватка возможности обработки ошибок: Опечатки в определении MIME типа или написания ключевого слова будут проигнорированы без каких-либо уведомлений об ошибках.
Отсутствие поддержки строки параметров: В связи с неопределённостью типа сегмента данных в Data URL, строка параметров (характерные для страницы параметры, представляющиеся в виде ), добавленная к сегменту данных будет рассматриваться, как часть этих данных.
Проблемы с безопасностью: Несколько проблем с безопасностью (например: фишинг) связаны с Data URL и переходом по ним из корневого контекста документа. Чтобы избавиться от этих проблем, переход по URI, начинающихся со схемы , из корневого контекста документа перестал быть возможен в Firefox, начиная с версии 59 (и начиная с версии 58 в Nightly/Beta вариантах браузера). Надеемся, что остальные браузеры так же последуют этому примеру. Для дополнительной информации смотрите Blocking Top-Level Navigations to data URLs for Firefox 58.

Запросы HTTP

HTTP запросы — это сообщения, отправляемые клиентом, чтобы инициировать реакцию со стороны сервера. Их стартовая строка состоит из трёх элементов:

Метод HTTP, глагол (например, , или ) или существительное (например, или ), описывающие требуемое действие. Например, указывает, что нужно доставить некоторый ресурс, а означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).
Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода. Это может быть
- Абсолютный путь, за которым следует и строка запроса. Это самая распространённая форма, называемая исходной формой (origin form) . Используется с методами , , , и .
- Полный URL — абсолютная форма (absolute form) , обычно используется с при подключении к прокси.
- Компонента URL «authority», состоящая из имени домена и (необязательно) порта (предваряемого символом ), называется authority form. Используется только с методом при установке туннеля HTTP.
- Форма звёздочки (asterisk form), просто «звёздочка» () используется и представляет сервер.
Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.

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

Существует множество заголовков запроса. Их можно разделить на несколько групп:

Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом
Заголовки запроса (Request headers), например, User-Agent (en-US), , уточняющие запрос (как, например, ), придающие контекст (как ), или накладывающие ограничения на условия (like ).
Заголовки сущности, например , относящиеся к телу сообщения. Как легко понять, они отсутствуют, если у запроса нет тела.

Последней частью запроса является его тело. Оно бывает не у всех запросов: запросы, собирающие (fetching) ресурсы, такие как , , , или , в нем обычно не нуждаются. Но некоторые запросы отправляют на сервер данные для обновления, как это часто бывает с запросами (содержащими данные HTML-форм).

Тела можно грубо разделить на две категории:

Одноресурсные тела (Single-resource bodies), состоящие из одного отдельного файла, определяемого двумя заголовками: и .
), состоящие из множества частей, каждая из которых содержит свой бит информации. Они обычно связаны с HTML-формами .

3.10 Метки языков (Language Tags).

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

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

           language-tag  = primary-tag *( "-" subtag )

           primary-tag   = 1*8ALPHA
           subtag        = 1*8ALPHA

Внутри метки не допустим пробел и все метки не чувствительны к
регистру. Пространство имен меток языка управляется IANA. Например
метки содержат:

          en, en-US, en-cockney, i-cherokee, x-pig-latin

Любая двухсимвольная первичная метка является меткой аббревеатуры
языка ISO 639, а любая двухсимвольная подчиненная метка является
меткой кода страны ISO 3166. (Последние три метки из
вышеперечисленных — не зарегистрированные метки; все, кроме
последней — примеры меток, которые могли бы быть зарегистрированы
в будущем.)

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

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

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

HTTP-сессия

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

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

В 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 сервер для сохранения информации или статуса о каждом пользователе в течение нескольких запросов. Однако некоторые веб-приложения реализовать состояния или сеансы на стороне сервера используя, например, HTTP куки или скрытый переменные в веб-формы.

HTTP сообщения

HTTP/1.1 и более ранние HTTP сообщения человекочитаемые. В версии HTTP/2 эти сообщения встроены в новую бинарную структуру, фрейм, позволяющий оптимизации, такие как компрессия заголовков и мультиплексирование. Даже если часть оригинального HTTP сообщения отправлена в этой версии HTTP, семантика каждого сообщения не изменяется и клиент воссоздаёт (виртуально) оригинальный HTTP-запрос. Это также полезно для понимания HTTP/2 сообщений в формате HTTP/1.1.

Существует два типа HTTP сообщений, запросы и ответы, каждый в своём формате.

Примеры HTTP запросов:

Запросы содержат следующие элементы:

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

Примеры ответов:

Ответы содержат следующие элементы:

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

Встречается в статьях

Инструкции:

Как настроить связку Apache + HTTP/2 на Linux CentOS 7
Как установить и настроить связку Asterisk + FreePBX на CentOS 8
Настройка веб-сервера на CentOS 7 со всем необходимым для правильной работы
Настройка веб-сервера на CentOS 8 со всем необходимым для правильной работы
Настройка безопасности Linux с помощью Fail2ban
Инструкция по установке и использованию GLPI на Linux CentOS
Установка и настройка веб-сервера IIS + PHP + MySQL
Настройка почтового сервера iRedMail на Ubuntu
Как настроить почту для корпоративной среды на CentOS 8
Как настроить почту для корпоративной среды на Ubuntu Server
Настройка веб-сервера на Ubuntu со всем необходимым для правильной работы
Как настроить NGINX с поддержкой HTTP/2
Трансляция видео с веб-сервера с помощью NGINX + rtmp
Как настроить почту на базе Postfix для корпоративной среды
Установка и настройка системы мониторинга Prometheus на Linux
Как установить и настроить прокси-сервер Squid на CentOS
Как установить и настроить прокси-сервер Squid на Ubuntu Server
Установка веб-сервера Apache на FreeBSD
Установка и настройка почтового сервера Zimbra на Linux
Как установить и использовать сервер хранения секретов Hashicorp Vault

Мини-инструкции:

Как настраивать перенаправления в сервере NGINX
Как настроить Apache для работы по HTTPS (SSL)
Как настроить HTTP/2 на Windows Server 2016 и выше
Инструкция по установке и настройке phplist
Как установить и настроить сервер Haproxy на Linux CentOS 7
Установка и настройка прокси-сервера 3proxy на Linux CentOS 7
Настройка проксирования почты с NGINX для IMAP, POP3 и SMTP
Настройка сервера мониторинга Zabbix на Linux CentOS 7
Настройка сервера мониторинга Zabbix на Ubuntu
Установка и настройка своего локального репозитория CentOS
Установка и настройка LDAP сервера FreeIPA на Linux CentOS
Установка и настройка CRM Битрикс24 от 1С на Linux CentOS
Включение кеширования ответа от backend в Nginx
Как пройти SSL-проверку при настройке https в NGINX
Инструкция по установке и настройке phplist на Linux Ubuntu
Установка и настройка модуля PageSpeed для NGINX и Apache
Установка и использование почтового клиента WebMail Lite на Linux CentOS
Настройка сервера мониторинга Zabbix 5 на Linux CentOS 8
Организация сервиса календаря и адресной книги на базе Baikal
Публикация баз 1С как веб-приложение в Apache на операционной системе Windows
Программный межсетевой экрана (маршрутизатор) pfSense — установка и настройка
Как настроить балансировку http-запросов в веб-сервере NGINX
Как настроить прозрачную аутентификацию в NGINX через LDAP
Как установить и настроить веб-сервер на базе NGINX + uWSGI для поддержки приложений на Python
Кластер серверов Hashicorp Vault с доступом через систему обнаружения Consul
Как установить и настроить Consul-агента и зарегистрировать на кластере сервис
Установка второго сервера FreeIPA с настройкой репликации

Резюме

Давайте теперь подведем итог нашему краткому разбору протокола HTTP.

Формат сообщений запроса и ответа сходен (различия есть в стартовой строке и заголовках сообщений). И, наконец, мы рассмотрели, как вы можете работать с заголовками запроса и ответа во фреймворках и библиотеках.

Понимание HTTP очень важно для реализации простого добротного RESTful (* веб-службы, построенные с учётом REST (передача состояния представления; архитектурный стиль взаимодействия компонентов распределенного приложения в сети)) интерфейса между двумя оконечными узлами локальной сети (* ЛС). По большому счету (* исходя из самых строгих требований) эти знания вам также пригодятся при создании вашей сетевой инфраструктуры (* совокупность аппаратных и программных средств, предоставляющая пользователю необходимые сетевые возможности) и обеспечении для конечных пользователей удобства использования

Во второй части мы разберем реализацию соединений, аутентификацию и кэширование! Тогда и увидимся.

Аутентификация

HTTP действительно поддерживает рудиментарную форму аутентификации, называемой Основной Проверкой Подлинности (Basic Authentication), точно также как и более надежную форму — Краткую Проверку Подлинности (Digest Authentication).

В Основной Проверке Подлинности сервер сразу же отвергает запрос клиента с WWW-Authenticate и кодом состояния 401 — Unauthorized. Увидев этот заголовок, браузер отображает диалоговое окно входа с запросом имени пользователя и пароля. Эта информация отправляется в фотмате BASE64 в заголовке запроса на аутентификацию. Теперь сервер может проверить запрос и разрешить доступ, если учетные данные верны. Некоторые серверы могут даже отправить заголовок Autentification-Info, содержащий дополнительные детали об аутентификации.

Следствием Основной Проверки Подлинности является Проверка Подлинности Прокси. Вместо веб-сервера, задача аутентификации состоит в запрашивании промежуточного прокси-сервера. Прокси-сервер отправляет заголовок Proxy-Authenticate с кодом статуса 407-Unauthorized. В свою очередь, клиенту предлагается посылать мандаты с помощью заголовка запроса Proxy-Authorization.

Краткая Проверка Подлинности похожа на Основную ПП техникой, схожей с WWW-Authenticate и заголовками авторизации, но Краткая ПП использует более надежные хэш-функции для шифрования имени пользователя и пароля (обычно- MD5 или KD дайджест-функций). Хотя Краткая ПП должна быть более безопасной, чем Основная ПП, веб-сайты обычно используют Основную ПП из-за её простоты. Для смягчения проблем безопасности Основные ПП используются в сочетании с SSL (Secure Sockets Layer).

Протокол Secure HTTP

Протокол HTTPS обеспечивает безопасное соединение в Интернете. Самый простой способ узнать, используете ли Вы его: проверить адресную строку браузера. Защищенный компонент HTTPs включает в себя вставленный слой шифрования / дешифрования между HTTP и TCP- Secure Sockets Layer (SSL) или улучшенный протокол Transport Layer Security (TLS).

SSL использует мощный алгоритм шифрования при помощи RSA и криптографии с открытым ключом. Так как безопасные транзакции в Интернете необычайно важны, разработка универсальных стандартов, основанных на Инфраструктуре Открытых Ключей (PKI) ведется уже давно.

Существующие клиенты / серверы не должны изменить способ обработки сообщения, так что большая часть тяжелой работы проходит в слое SSL. Таким образом, вы можете разрабатывать веб-приложения, используя Основные ПП и автоматически пользоваться преимуществами SSL за счет перехода на протокол https://. Однако, чтобы веб-приложение работало на протоколе HTTPS, необходимо иметь рабочий цифровой сертификат, развернутый на сервере.

Сертификаты

Также как человеку нужен паспорт для удостоверения личности, серверу нужен цифровой сертификат для идентификации. Сертификаты (или “certs”) выдаются Центром Сертификации (CA) и поручаются за Вашу личность в Интернете. CA хранят в себе PKI. Наиболее распространенная форма сертификатов- стандарт X.509 v3, который содержит такую информацию:

поставщик сертификата,
алгоритм сертификации,
имя субъекта или организации, для которой создается сертификат,
открытый ключ информации для субъекта,
Сертифицированная Подпись, использовавшая заданный алгоритм подписи.

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

Как только сертификат сверен, вступает в силу полная и безопасная передача SSL.

Ответы HTTP

Стартовая строка ответа HTTP, называемая строкой статуса, содержит следующую информацию:

Версию протокола, .
Код состояния (status code), показывающая, был ли запрос успешным. Примеры: , или
Пояснение (status text). Краткое текстовое описание кода состояния, помогающее пользователю понять сообщение HTTP..

Пример строки статуса:

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

Существует множество заголовков ответов. Их можно разделить на несколько групп:

Основные заголовки (General headers), например, Via (en-US), относящиеся к сообщению в целом.
Заголовки ответа (Response headers), например, и , сообщающие дополнительную информацию о сервере, которая не уместилась в строку состояния.
Заголовки сущности (Entity headers), например, , относящиеся к телу ответа. Отсутствуют, если у запроса нет тела.

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

Тела можно разделить на три категории:

Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла известной длины, определяемые двумя заголовками: и .
Одноресурсные тела (Single-resource bodies), состоящие из отдельного файла неизвестной длины, разбитого на небольшие части (chunks) с заголовком Transfer-Encoding (en-US), значением которого является .
, состоящие из многокомпонентного тела, каждая часть которого содержит свой сегмент информации. Они относительно редки.

Other Areas and Protocols

The HTTP-NG activity has information about Â the former W3C
HTTP-NG Activity
The Propagation, Caching and Replication
area has a lot of information about caching schemes and scalability
Internet Message Access Protocol
(IMAP) is a method of accessing electronic mail or bulletin board
messages that are kept on a (possibly shared) mail server
Next Generation Internet (NGI)
Initiative. On October 10, 1996, President Clinton and Vice President
Gore announced their commitment to the Next Generation Internet (NGI)
Initiative, based upon strong research and development programs across
Federal agencies.
The Web Robots Pages —
information about Web robots and how to manage them
What’s the Internet
weather like? A really useful service from UCLA
A few other Internet protocols
relevant to HTTP

Yves Lafon
, @(#) $Id: Overview.html,v 1.244 2014-06-11 14:21:46 ylafon Exp $

Структура HTTP-ответа на основе примера выше

Можно заметить, что структура ответа похожа на структуру запроса. Но есть несколько нюансов. Первая строка ответа выглядит иначе:

протокол

Значение поля то же самое, что и в запросе. Но может отличаться от версии, что запросил браузер, если веб-сервер её не понимает.

статус и пояснение

HTTP-статус из трёх цифр и короткая поясняющая фраза. Все фразы стандартизированы и чётко соответствуют статусу.

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

Первая цифра статуса указывает на класс:

1xx — информационные — технические статусы, вероятнее всего вы их не увидите в реальной жизни
2xx — успешно обработанные запросы с детализацией. Наиболее частые: 200 — всё ок, 201 — документ был создан, 204 — запрос завершился успешно, но ответ содержит заголовки и пустое тело. На практике реальные API не парятся и в 95% случаев возвращают код 200, а детали успешной операции отсылаются в теле.
3xx — перенаправление — запрос следует выполнить по другому адресу, который передаётся в заголовке Location. Частые: 301 — документ перенесён навсегда, 302 — документ перенесён временно. Они довольно критичны для поисковых ботов, которые индексируют ваш сайт. 301 говорит боту, чтобы он запомнил новый адрес страницы, а прежний забыл.
4xx — ошибка клиента — запрос содержит не все или некорректные данные (400), требуется аутентификация (401) или не хватает прав на выполнение операции (403), запрошенной страницы не существует (404) или http метод запроса для этой страницы запрещён (405).
5xx — ошибка на сервере — сервер не справился или произошла непредвиденная ошибка (500), ошибка обработки запроса вышестоящим сервером, например php-fpm не отвечает nginx’у (502), сервер временно не отвечает по техническим причинам (503), сервер не дождался ответа и запрос отвалился по таймауту (504). Например, стандартное ограничение на время выполнения php-скрипта — 30 секунд. Если скрипт делает запрос к стороннему ресурсу, который под нагрузкой, то nginx покажет 504ю ошибку.

При этом даже неуспешный статус не запрещает серверу вернуть веб-страницу, которую браузер отобразит как ни в чём не бывало. Попробуйте зайти на несуществующую страницу моего блога: https://maxkuznetsov.ru/non-existed-page. Сервер вернёт 404 вместо 200, но мы всё равно можем показать пользователю что-то полезное.

заголовки

Заголовки сервера выполняют ту же роль, что и заголовки запроса. Есть общие заголовки, как Cache-Control, но есть и свои уникальные.

Allow — определяет список разрешённых http методов для запросов
Location — адрес для перенаправления.
WWW-Authenticate — информация про метод аутентификации, запрос должен послать соответствующую информацию в хедере Authorization.

тело

Тело ответа также отделяется от группы заголовков пустой строкой. При этом в теле может передаваться что угодно — текст, html, json, xml, картинки и прочие файлы. Все они отдаются браузеру в одинаковом формате, но с отличающемся заголовком Content-Type, который и поясняет браузеру, как отобразить контент пользователю: как html-страницу, как картинку, показать встроенный в браузер PDF-просмотрщик или начать скачивание файла.

HTTP Mailing lists

There are several mailing lists that you are welcome to use. As several of
them are very high volume then please check out the archives first to see if
the topic that you want to bring up in fact already has been discussed. As we
try to make as much progress on HTTP as possible it is very important that we
can stay focused — even on open mailing lists!

ietf-http-wg@w3.org (Archived at W3C (see also the 1994 to 2002 archives).: The official mailing list of the IETF HTTP working group.
w3c-http@w3.org (Archive): This is a W3C mailing list dedicated to promote HTTP/1.1
implementation, to gain sufficient experience among W3C Members to
support the specification, and ease; development of HTTP/1.1 software and applications. The list is only
accessible to W3C members.
www-talk@w3.org (Archive): This is the primary public mailing list for technical
discussion among those developing World Wide Web software. It
is explicitly intended for the collaborative design of new systems,
software, protocols, and documentation which may be useful to the WWW
developer community. General questions from non-developers should go
one of the many newsgroups.
www-speed@tipper.oit.unc.edu (Information): This list is no longer maintained and is not active anymore.
Do not post any mails to this address!