Протокол HTTP и работа с заголовками
Как работает WWW (всемирная паутина, веб) в двух словах:
- браузер пользователя (клиент) отправляет на сервер запрос с адресом сайта (URL);
- сервер получает этот запрос и отдаёт клиенту требуемый тому контент.
Иными словами, весь современный веб построен на модели клиент-серверного взаимодействия. И чтобы весь этот процесс оказался возможным, необходим универсальный язык-протокол, который будет понимать и сервер, и браузер. Такой протокол есть, а называется он HTTP.
Как работает HTTP, и зачем нам это знать
Программировать на PHP можно и без знания протокола HTTP, но есть ряд ситуаций, когда для решения задач нужно знать, как именно работает веб-сервер. Ведь PHP — это, в первую очередь, серверный язык программирования.
Протокол HTTP очень прост и состоит, по сути, из двух частей:
- Заголовков запроса/ответа;
- Тела запроса/ответа.
Сначала идёт список заголовков, затем пустая строка, а затем (если есть) тело запроса/ответа.
И клиент, и сервер могут посылать друг другу заголовки и тело ответа, но в случае с клиентом доступные заголовки будут одни, а с сервером — другие. Рассмотрим пошагово, как будет выглядеть работа по протоколу HTTP в случае, когда пользователь хочет загрузить главную страницу социальной сети «Вконтакте».
1. Браузер пользователя устанавливает соединение с сервером vk.com и отправляет следующий запрос:
2. Сервер принимает запрос и отправляет ответ:
3. Браузер принимает ответ и показывает готовую страницу
Больше всего нам интересен самый первый шаг, где браузер инициирует запрос к серверу vk.com
Рассмотрим подробнее, что там происходит. Первая строка запроса определяет несколько важных параметров, а именно:
- Метод, которым будет запрошен контент;
- Адрес страницы;
- Версию протокола.
GET — это метод (глагол), который мы применяем для доступа к указанной странице.
GET является самым часто используемым методом, потому что он говорит серверу о том, что клиент всего лишь хочет прочитать указанный документ. Но помимо GET есть и другие методы, один из них мы рассмотрим уже в следующем разделе.
После метода идет указание на адрес страницы — URI (универсальный идентификатор ресурса). В нашем случае мы запрашиваем главную страницу сайта, поэтому используется просто слэш — / .
Последним в этой строке идет версия протокола и почти всегда это будет HTTP/1.1
После строки с указанием основных параметров всегда следует перечисление заголовков, которые передают серверу дополнительную полезную информацию: название и версию браузера, язык, кодировку, параметры кэширования и так далее.
Среди всех этих заголовков, которые передаются при каждом запросе, есть один обязательный и самый важный — это заголовок Host . Он определяет адрес домена, который запрашивает браузер клиента.
Сервер, получив запрос, ищет у себя сайт с доменом из заголовка Host , а также указанную страницу.
Если запрошенный сайт и страница найдены, клиенту отправляется ответ:
HTTP/1.1 200 OK
Такой ответ означает, что всё хорошо, документ найден и будет отправлен клиенту. Если говорить более обобщённо, стартовая строка ответа имеет следующую структуру:
HTTP/Версия Код состояния Пояснение
Больше всего здесь интересен именно код состояния, он же код ответа сервера.
В этом примере код ответа — 200, что означает: сервер работает, документ найден и будет передан клиенту. Но не всегда всё идет гладко.
Например, запрошенный документ может отсутствовать или сервер будет перегружен, в таком случае клиент не получит контент, а код ответа будет отличным от 200.
- 404 — если сервер доступен, но запрошённый документ не найден;
- 503 — если сервер не может обрабатывать запросы по техническим причинам.
Спецификация HTTP 1.1 определяет 40 различных кодов HTTP.
После стартовой строки следуют заголовки, а затем тело ответа.
Работа с заголовками в PHP
В PHP есть все возможности для взаимодействия с протоколом HTTP:
- Получение тела запроса;
- Получение заголовков запроса;
- Добавление/изменение заголовков ответа;
- Управление телом ответа.
Разберём всё по порядку.
Получение тела запроса
Тело запроса — это информация, которую передал браузер при запросе страницы.
Но тело запроса присутствует только если браузер запросил страницу методом POST .
Дело в том, что POST — это метод, специально предназначенный для отправки данных на сайт. Чаще всего метод POST браузер задействует в момент отправки формы. В этом случае телом запроса будет содержимое формы.
В PHP-сценарии все данные отправленной формы будут доступны в специальном массиве $_POST . Более подробно об этом написано в следующей главе, посвящённой формам.
Получение заголовков запроса
Напомним ещё раз, что заголовки запроса — это мета-информация, отправленная браузером при запросе сценария.
PHP автоматически извлекает такие заголовки и помещает их в специальный массив — $_SERVER .
Стоит отметить, что в этом массиве, помимо заголовков, есть и другая информация. Значения заголовков запроса находятся под ключами, которые начинаются с HTTP_ . Подробно всё содержимое этого массива описано в официальной документации.
Пример, как получить предыдущую страницу, с которой перешёл пользователь:
Добавление/изменение заголовков ответа
В PHP-сценарии можно управлять всеми заголовками ответа, которые попадут к пользователю вместе с контентом страницы. Это возможно, потому что PHP работает на стороне веб-сервера и имеет с ним очень тесную интеграцию.
Вот примеры сценариев, когда пригодится управление заголовками ответа:
- Кэширование;
- Переадресация пользователя;
- Установка cookies;
- Отправка файлов;
- Передача дополнительной информации браузеру.
Заголовки ответа нужны для выполнения множества важных задач.
В PHP есть функция для отправки или смены заголовков: header() .
Она принимает имя и значение заголовка и добавляет его в список из всех заголовков, которые уйдут в браузер пользователя после окончания работы сценария.
Например, так выполняется перенаправление пользователя на другую страницу:
За переадресацию отвечает заголовок с именем Location , а через двоеточие задаётся значение — адрес страницы для перехода.
Важное замечание по использованию заголовков
Есть одно ограничение: заголовки нельзя отправлять, если пользователю к этому моменту уже отправили любой контент. То есть, если показать что-то на экране, например, через функцию print() , то после этого заголовки поменять уже не получится.
Управление телом ответа
Всё, что PHP выводит на экран, является содержимым ответа. Иными словами, вызовы функций print , echo или показ текста через шорт-теги являются телом ответа, которое попадает в браузер пользователю.
Параметры запроса
Мы привыкли, что на нашем сайте каждый PHP-сценарий отвечает за одну страницу. Посетитель сайта вводит в адресную строку путь, который состоит из имени домена и имени PHP-сценария. Например, так: http://weather-diary.ru/day.php .
Но как быть, если одна страница должна показывать разную информацию?
На сайте дневника наблюдений за погодой мы сделали отдельную страницу, чтобы показывать на ней информацию о погоде из истории за один конкретный день. То есть страница одна, но показывает разные данные, в зависимости от выбранного дня.
Также пользователи хотят добавить в закладки адреса страниц с нужными им днями. Получается, что имея только один сценарий сделать страницу, способную показывать дневник погоды за любой день невозможно? Вовсе нет!
Из чего состоит URI
URI — это уникальный идентификатор ресурса. Ресурс в нашем случае — это полный путь до страницы сайта. И вот как может выглядеть ресурс для показа погоды за конкретный день:
http://weather-diary.ru/day.php?date=2017-10-15
Разберем, из чего состоит этот URI.
Во-первых, здесь есть имя домена: weather-diary.ru .
Затем идёт имя сценария: day.php
А всё что идёт после — это параметры запроса.
Параметры запроса — это как бы дополнительные атрибуты адреса страницы. Они отделяются от имени страницы знаком запроса. В примере выше параметр запроса только один: date=2017-10-30.
Имя этого параметра: date , значение: 2017-10-15 .
Параметров запроса может быть несколько, тогда они разделяются знаком амперсанда: ?date=2017-10-15&tscale=celsius
В примере выше указывается два аргумента: дата и единица измерения температуры.
Параметры запроса как внешние переменные
Теперь в адресе страницы используются параметры запроса, но какая нам от этого польза? Она состоит в том, что если имя страницы вызывает к исполнению соответствующий PHP-сценарий, то параметры запроса превращаются в специальные внешние переменные в этом сценарии. То есть, если в адресе присутствуют такие параметры, то их легко получить внутри кода сценария и выполнить с ними какие-нибудь действия. Например, показать погоду за конкретный день в выбранных единицах измерения.
Получение параметров запроса
Если есть внешние переменные, то как их прочитать?
Все параметры запроса находятся в специальном, ассоциативном массиве $_GET , а значит сценарий, вызванный с таким адресом: day.php?date=2017-10-15&tscale=celsius будет иметь в этом массиве два значения с ключами date и scale .
Запрос на получение данных за выбранный день выглядит так:
В первой строчке примера выше мы получаем значение параметра date , а если он отсутствует, то используем текущую дату в качестве выбранного дня.
Никогда не полагайтесь на существование параметра в массиве $_GET и делайте проверку либо функцией isset() , либо как в этом примере.
В этом задании вы сможете потренироваться использовать $_GET .
Формирование URI с параметрами запроса
Иногда нужно совершить обратную операцию: сформировать адрес страницы, включив туда нужные параметры запроса из массива.
Скажем, на странице погодного дневника надо поставить ссылку на следующий и предыдущий день. Нужно также сохранить выбранную единицу измерений. То есть необходимо сохранить текущие параметры запроса, поменять значение одного из них (день), и сформировать новую ссылку.
Вот как это можно сделать:
Всё что нужно знать про HTTP

HTTP расшифровывается «как протокол передачи гипертекста» — это протокол связи, используемый для просмотра веб-страниц. Этот протокол использует модель на основе сообщений — клиент совершает HTTP-запрос к серверу, на который сервер отвечает ресурсом, который отображается в браузере.
Каждое взаимодействие через HTTP включает в себя запрос и ответ. По своей природе HTTP не имеет состояния.
Без состояния означает, что все запросы отделены друг от друга, а значит —каждый запрос должен содержать достаточно информации, чтобы полностью выполниться. Это означает, что каждая транзакция HTTP-модели, основанной на сообщениях, обрабатывается отдельно от остальных.
URL
URL (унифицированный указатель ресурса) — вероятно, самая известная концепция интернета. Это также одна из самых важных и полезных концепций. URL-адрес — это веб-адрес, используемый для идентификации ресурсов в интернете.
Идея интернета структурирована вокруг ресурсов, с самого начала интернет был платформой для обмена текстовыми/HTML — файлами, документами, изображениями и т.д, и поэтому он может рассматриваться как совокупность ресурсов.
Протокол (Protocol — обычно это HTTP (или HTTPS для защищённой версии HTTP)
Другие примечательные протоколы:
- File Transfer Protocol (FTP) — это стандартный протокол, используемый для передачи файлов между клиентом и сервером по сети.
- Simple Mail Transfer Protocol (SMTP) является стандартом для передачи электронной почты.
Домен (Domain) — имя для идентификации одного или нескольких IP-адресов, на которых расположен ресурс.
Путь (Path) — указывает местоположение ресурса на сервере. Использует ту же логику, что и расположение ресурса на устройстве, которое вы читаете в этой статье (например, /search/cars/VWBeetle.pdf или C:/mycars/VWBeetle.pdf).
Параметры (Parameters) — дополнительные данные, используемые для идентификации или фильтрации ресурса на сервере.
Нужно заметить
При поиске статей и дополнительной информации об HTTP вы можете встретить термин URI (унифицированный идентификатор ресурса). URI иногда используется вместо URL, но в основном в формальных спецификациях и людьми, которые хотят похвастаться
HTTP-запросы
В HTTP каждый запрос должен иметь URL-адрес. К тому же, запросу необходим метод. Четыре главных HTTP метода это:
Я объясню эти и другие методы в разделе «HTTP-методы» этой статьи.
Эти методы прямо соответствуют действиям:
Все HTTP-сообщения имеют один или несколько заголовков, за которыми следует необязательное тело сообщения. Тело содержит данные, которые будут отправлены с запросом, или данные, полученные с ответом.
Первая часть каждого HTTP-запроса содержит три элемента:
- _GET/adds/search-result?item=vw+beetleHTTP/1.1_
Когда URL содержит знак «?» это означает, что он содержит запрос. Это означает, что он отправляет параметры запрошенного ресурса.
- Первая часть — это метод, который сообщает, какой метод HTTP используется. Чаще всего используется метод GET. Метод GET извлекает ресурс с веб-сервера, и поскольку у GET нет тела сообщения, после заголовка ничего не требуется
- Вторая часть — запрошенный URL.
- Третья часть — используемая версия HTTP. Версия 1.1. является наиболее распространенной для большинства браузеров, однако, версия 2.0 становится популярнее.
В HTTP-запросе есть и другие интересные вещи:
Referer header — сообщает URL-адрес, с которого поступил запрос.
User-Agent header — дополнительная информация об используемом браузере.
Host header — показывает имя хоста. Его следует уникально идентифицировать, это необходимо, когда несколько веб-страниц размещаются на одном сервере.
Cookie header — отправляет дополнительные параметры на клиент.
HTTP-ответы
Как и HTTP-запросы, HTTP-ответы состоят из трех элементов:
Например:
_HTTP/1.1 200 OK_
- Первая часть — версия HTTP.
- Вторая часть — цифровой код результата запроса.
- Третья часть — текстовое объяснение второй части.
В HTTP-ответе есть и другие интересные вещи:
Server header — показывает программное обеспечение сервера.
Set-Cookie header — используется для создания cookie в браузере.
Message body — обычно HTTP-ответ содержит тело сообщения.
Content-Length header — сообщает размер тела сообщения в байтах.
HTTP-методы
Наиболее распространёнными методами являются GET и POST, но бывают и другие.
GET — используется для запросы данных с определенного ресурса, на котором данные не изменяются, поскольку GET-запросы не изменяют состояние ресурса.
POST — используется для отправки данных на сервер для создания ресурса.
PUT — метод для обновления существующего на сервере ресурса, используя содержимое тела запроса.
HEAD — этот метод выполняет ту же функцию, что и GET-метод, но с той разницей, что HEAD не содержит тело запроса. Но он вернёт те же заголовки, что и метод GET. Метод HEAD используют для проверки существования ресурса, перед выполнением метода GET.
TRACE — метод предназначен для диагностических целей. Ответ будет содержать в своем теле точное содержание запроса.
OPTIONS — этот метод используется для описания параметров связи (методов HTTP), доступных для целевого ресурса.
PATCH — используется для применения частичных модификаций к ресурсу..
DELETE — удаляет определённый ресурс.
REST
Передача репрезентативного состояния (REST) — это стиль архитектуры, в котором запрос и ответы содержат представление текущего состояния системного ресурса.
- _http://carapp.com/search?make=wv&model=beetle_
- _http://carapp.com/search/vw/beetle_
Я буду говорить больше о REST API в других статьях, следите за новостями.
HTTP-заголовки
Струтура запроса/ответа состоит из трёх частей:
- Первая строчка
- Заголовки
- Тело
Мы уже говорили о первой строке в HTTP-запросах и ответах, упоминали тело, а теперь поговорим о HTTP-заголовках.
HTTP-заголовки добавляются после первой строки и определяются как пары _имя:значение_, разделённые двоеточием. HTTP-заголовки используются для отправки дополнительных параметров вместе с запросом или ответом. Как мы уже говорили, тело сообщения содержит данные, которые будут отправлены вместе с запросом, или данные, полученные вместе с ответом.
Существуют различные типы заголовков, которые мы группируем на основе их использования в 4 широких категорий:
General header (Главные заголовки) — могут использоваться для всех типов сообщений (запроса и ответа) и независимы от передаваемых данных.
Request header (Заголовки запроса) — определяют параметры для запрашиваемых данных или параметры с важной информацией о клиенте, совершающем запрос.
Response header (Заголовки ответа) — содержат информацию об ответе
Entity header (Заголовки сущностей) — описывают содержимое, которое составляет тело сообщения.
HTTP-коды ответов
Каждый HTTP-ответ должен содержать код состояния HTTP, сообщающий результат запроса.
Существует пять групп кодов состояния. Их группируют по первой цифре:
- 1xx — Информационные.
- 2xx — Запрос прошел успешно.
- 3xx — Клиент был перенаправлен на другой ресурс.
- 4xx — Запрос содержит ошибку.
- 5xx — Сервер совершил ошибку при выполнении запроса.
HTTPS (Hypertext Transfer Protocol Secure)
Безопасной версией протокола HTTP является HyperText Transfer Protocol Secure — защищённый протокол передачи гипертекста (HTTPS). HTTPS обеспечивает шифрованную связь между браузером (клиентом) и веб-сайтом (сервером).
В HTTPS протокол связи шифруется с использованием безопасности транспортного уровня (TLS) или уровня защищенных сокетов (SSL).
Также протокол часто называют HTTP поверх TLS или HTTP поверх SSL.
Оба протокола TLS и SSL используют систему асимметричного шифрования. Система асимметричного шифрования использует открытый ключ (ключ шифрования) и закрытый ключ (ключи дешифрования) для шифрования сообщения. Любой может использовать открытый ключ для шифрования сообщения. Однако закрытые ключи являются секретными, и это означает, что только предполагаемый получатель может расшифровать сообщение.
SSL/TLS handshake
При запросе HTTPS-соединения с сайтом, сайт отправляет свой SSL-сертификат вашему браузеру. Этот процесс, когда ваш браузер и веб-сайт инициируют связь, называется «SSL/TLS handshake».
SSL/TLS handshake включает в себя ряд шагов, когда браузер и веб-сайт проверяют друг друга и начинают связь через туннель SSL/TLS.
Можно заметить, что во время соединения HTTPS используется надежный защищённый туннель и в адресной строке браузера отображается зеленый значок замка.
Заголовки HTTP
Заголовки HTTP позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после ( : ) непосредственно значение. Пробелы перед значением игнорируются.
Пользовательские собственные заголовки исторически использовались с префиксом X, но это соглашение было объявлено устаревшим в июне 2012 года из-за неудобств, вызванных тем, что нестандартные поля стали стандартом в RFC 6648 ; другие перечислены в реестре IANA, исходное содержимое которого было определено в RFC 4229. IANA также поддерживает реестр предлагаемых новых заголовков HTTP.
HTTP-заголовки сопровождают обмен данными по протоколу HTTP. Они могут содержать описание данных и информацию, необходимую для взаимодействия между клиентом и сервером. Заголовки и их статусы перечислены в реестре IANA, который постоянно обновляется.
Заголовки могут быть сгруппированы по следующим контекстам:
-
применяется как к запросам, так и к ответам, но не имеет отношения к данным, передаваемым в теле. содержит больше информации о ресурсе, который нужно получить, или о клиенте, запрашивающем ресурс . содержат дополнительную информацию об ответе, например его местонахождение, или о сервере, предоставившем его. содержат информацию о теле ресурса, например его длину содержимого или тип MIME.
Заголовки также могут быть сгруппированы согласно тому, как прокси (proxies) обрабатывают их:
Сквозные заголовки
Эти заголовки должны быть переданы конечному получателю сообщения: серверу для запроса или клиенту для ответа. Промежуточные прокси-серверы должны повторно передавать эти заголовки без изменений, а кеши должны их хранить.
Хоп-хоп заголовки (Хоп-хоп заголовки)
Эти заголовки имеют смысл только для одного соединения транспортного уровня и не должны повторно передаваться прокси или кешироваться. Обратите внимание, что с помощью общего заголовка Connection могут быть установлены только заголовки переходов.
Аутентификация
WWW-Authenticate (en-US)
Определяет метод аутентификации, который должен использоваться для доступа к ресурсу.
Authorization
Содержит учётные данные для аутентификации агента пользователя на сервере.
Proxy-Authenticate (en-US)
Определяет метод аутентификации, который должен использоваться для доступа к ресурсам на прокси-сервере.
Proxy-Authorization (en-US)
Содержит учётные данные для аутентификации агента пользователя с прокси-сервером.
Ниже перечислены основные HTTP заголовки с кратким описанием:
| Заголовок | Описание | Подробнее | Стандарт |
|---|---|---|---|
| Accept | Список MIME типов, которые ожидает клиент. | HTTP Content Negotiation | HTTP/1.1 |
| Accept-CH |
For the rel=prefetch case, see Link Prefetching FAQ
Introduced in HTTP 1.1’s RFC 2068, section 19.6.2.4, it was removed in the final HTTP 1.1 spec, then reintroduced, with some extensions, in RFC 5988
Содержит URL-адрес ресурса, из которого был запрошен обрабатываемый запрос. Если запрос поступил из закладки, прямого ввода адреса пользователем или с помощью других методов, при которых исходного ресурса нет, то этот заголовок отсутствует или имеет значение «about:blank».
Это ошибочное имя заголовка (referer, вместо referrer) было введено в спецификацию HTTP/0.9, и ошибка должна была быть сохранена в более поздних версиях протокола для совместимости.
Примечание
Note: The Keep-Alive request header is not sent by Gecko 5.0 ; previous versions did send it but it was not formatted correctly, so the decision was made to remove it for the time being. The Connection or Proxy-Connection header is still sent, however, with the value «keep-alive».
HTTP-заголовки, которые влияют на SEO

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

Код состояния (200OK, 301, 429, 500 и другие) является лишь частью полного HTTP-ответа, который сервер отправляет клиенту. Полный ответ кода состояния плюс дополнительная информация называется заголовком HTTP.
Этот заголовок может содержать инструкции, которые клиенты и поисковые системы могут использовать для правильной обработки URL.
Важные HTTP-заголовки для SEO
Далее рассмотрим ряд важных элементов заголовка HTTP для SEO.
X-Robots-Tag
Это аналог метатега robots в html. У данного элемента есть преимущества над meta name=“robots”. Например, если вы хотите запретить к индексации файлы PDF, метатег robots не поможет, так как он не работает с PDF-файлами. Вместо этого, вы можете использовать заголовок X-Robots-Tag.
К тому же у X-Robots-Tag есть ещё одно преимущество – его легко настраивать для целых каталогов и папок, что может ускорить работу.
Помимо «noindex» и «nofollow», вы можете прописать другие ответы X-Robots-Tag. Директивы из справки Google — ссылка:

Canonical
Обычно теги canonical расположены в исходном HTML-коде веб-страницы. Однако вы также можете указать канонический URL как часть HTTP-заголовка URL.
Поскольку реализовать тег rel= “canonical” в HTML довольно просто, редко можно найти канонические ссылки, отправленные как часть HTTP-ответа страницы. Однако всегда стоит перепроверить HTTP Headers страницы на наличие канонических ссылок, особенно если вы видите на сайте необычные проблемы с индексацией и ранжированием. Как именно проверить заголовки сайта, мы расскажем чуть ниже.
Hreflang
Так же, как канонические ссылки, вы можете включить ссылки hreflang в ответ HTTP-заголовка страницы, чтобы сообщить поисковым системам об альтернативных версиях страницы на разных языках и/или для разных стран.
Cache-control
Cache-control может влиять на то, как браузер кэширует страницу и связанные с ней ресурсы. Например, вы можете предоставить ответ «max-age», который сообщает браузеру, что через некоторое время страница должна быть повторно запрошена с сервера. В противном случае кэш страницы действителен то время, которое указано в значении «max-age», тем самым ускоряя скорость загрузки страницы. Директивы из справки Google — ссылка:

Служит для определения различий отображения контента для ПК и мобильных устройств. Особенно это важно для сайтов, которые используют динамический показ для мобильных пользователей. Для сайтов с адаптивным дизайном данный элемент не так актуален.
При правильной настройке заголовка Vary поисковые боты будут сканировать сайт со всеми указанными типами User-agent и определять, какая версия кода будет ранжироваться для какого типа пользователей.
Last-Modified
В значении Last-Modified необходимо указывать дату последнего изменения ресурса. HTTP Header используется для сравнения нескольких версий одного и того же ресурса. Он тесно связан с заголовками If-Modified-Since и If-Unmodified-Since.
If-Modified-Since
Это условный запрос, который передаёт объект, если он был изменен после указанной даты. То есть передаются данные только в том случае, когда кэш устарел.
If-Unmodified-Since
Это условный запрос, который передаёт объект, только если он не был изменен после указанной даты.
Expires
Дата/время, после которого ответ веб-сервера считается устаревшим. Например, можно указывать текущую дату + 7/10/14 дней.
Accept-Encoding
Алгоритм кодирования, обычно алгоритм сжатия, который можно использовать на отправленном ресурсе. Это заголовок запроса, который запрашивает HTTP-клиент, чтобы сообщить серверу, какую кодировку он поддерживает. Серверу разрешено отправлять содержимое ответа в любой из этих кодировок.
Content-Encoding
Используется для указания алгоритма сжатия. Это заголовок ответа, в котором HTTP-сервер использует этот заголовок, чтобы сообщить клиенту, в какую именно кодировку фактически был закодирован контент.
Content-Length
Размер ресурса в десятичном числе байтов.
Content-Type
Указывает тип носителя ресурса.
Location
Указывает URL-адрес для перенаправления страницы. Он используется только тогда, когда для пользователя указывается перенаправление на другую страницу (3xx код) или при новом местоположении ресурса (201 код).
Проверка HTTP Headers
Далее рассмотрим некоторые способы, как посмотреть HTTP-заголовки страницы или отдельного файла.
Просмотр HTTP-заголовков в браузере Google Chrome
HTTP Headers в Chrome можно найти в инструментах разработчика. Для этого необходимо нажать либо Ctrl+Shift+I (многие используют просто F12), либо правой кнопкой мыши и выбрать пункт «Посмотреть код», либо в верхнем выпадающем меню браузера выбрать «Дополнительные инструменты» → «Инструменты разработчика».

После чего выбрать вкладку «Network» и обновить страницу (F5).

Далее в графе «Name» необходимо выбрать тип файла, для которого вы хотите проверить заголовки, и справа во вкладке «Headers» будут указаны все заголовки текущего файла.

Просмотр HTTP-заголовков в браузере Firefox
Аналогичным способом можно проверить заголовки и в Firefox: при помощи Ctrl+Shift+C либо в верхнем выпадающем меню выбрать «Веб-разработка»→«Инструменты разработчика». Далее выбрать вкладку «Сеть» и обновить страницу (F5). После чего выбрать тип документа для проверки и в правой части экрана выбрать вкладку «Заголовки». Перед вами появятся заголовки текущей страницы.

Другие способы проверки HTTP-заголовков
Для того чтобы посмотреть HTTP-заголовки в два счёта, есть множество расширений для любого браузера, будь то Google Chrome, Mozilla Firefox или Internet Explorer.
Примеры популярных расширений:
- Live HTTP Headers для Mozilla Firefox.
- HTTP Header Spy для Google Chrome и Mozilla Firefox.
- Microsoft Fiddler для Internet Explorer.
- Web Developer для Chrome, Mozilla Firefox и Opera.
Также в сети есть большое количество онлайн-программ, при помощи которых вы можете проверить заголовки своего сайта:
Вдобавок в Яндекс.Вебмастере и Google Search Console также есть инструменты проверки HTTP Headers.
В заключение
Внедрение HTTP-заголовков особенно актуально для средних и крупных сайтов для ускорения работы веб-сервера, а также уменьшения расхода краулингового бюджета на ресурсы, которые нет необходимости повторно скачивать. Подробнее о том, какими ещё способами можно увеличить краулинговый бюджет сайта, читайте в статье: https://siteclinic.ru/blog/technical-aspects/kak-uvelichit-kraulingovyj-byudzhet/.
Если Вы хотите исправить все ошибки оптимизации на сайте, обращайтесь к нам!
Что такое HTTP
HTTP (HyperText Transfer Protocol — «протокол передачи гипертекста») — протокол прикладного уровня передачи данных (изначально — в виде гипертекстовых документов). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом.
HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.
Основным объектом манипуляции в HTTP является ресурс, на который указывает Что такое URI с примерами (Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.
Возможности протокола легко расширяются благодаря внедрению своих собственных заголовков, сохраняя совместимость с другими клиентами и серверами. Они будут игнорировать неизвестные им заголовки, но при этом можно получить необходимую функциональность при решении специфической задач.
HTTP/1.1 — текущая версия протокола. Новым в этой версии был режим «постоянного соединения»: TCP-соединение может оставаться открытым после отправки ответа на запрос, что позволяет посылать несколько запросов за одно соединение. Клиент теперь обязан посылать информацию об имени хоста, к которому он обращается, что сделало возможным более простую организацию виртуального хостинга.
HTTP не сохраняет информацию по транзакциям, поэтому в следующей транзакции приходится начинать все заново. Преимущество состоит в том, что HTTP сервер может обслужить в заданный промежуток времени гораздо больше клиентов, ибо устраняются дополнительные расходы на отслеживание сеансов от одного соединения к другому. Есть и недостаток: для сохранения информации по транзакциям более сложные CGI- программы должны пользоваться скрытыми полями ввода или внешними средствами, например Cookie.
Методы HTTP запроса
Метод HTTP — последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.
Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он не применим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.
Кроме методов GET и HEAD, часто применяется метод POST.
HEAD HTTP запрос — аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Проверка наличия ресурса. Может кэшироваться.
OPTIONS — запрашивает информацию о коммуникационных параметрах сервера. Чтобы запросить данные обо всем сервере в целом, вместо URI запроса следует использовать символ *.
TRACE — требует, чтобы тело содержимого запроса было возвращено без изменений. Используется для отладки.
При запросе методом GET данные передаются в виде значений переменных. В стандарте Что такое URI с примерами(URL +URN) можно использовать только ограниченный набор символов. Для передачи в URI символов кириллицы их перекодируют в два этапа. На первом этапе каждый символ кодируется в Unicode (UTF-8) в последовательность из двух байт, на втором этапе каждый байт этой последовательности записывается в шестнадцатеричном представлении.
Заголовки (параметры) HTTP запроса, ответа, сущности
Все заголовки в протоколе HTTP разделяются на четыре основных группы (в нижеприведенном порядке рекомендуется посылать заголовки получателю):
Entity Headers (Заголовки сущности) — сопровождают каждую сущность сообщения. В отдельный класс заголовки сущности выделены для того, чтобы не путать их с заголовками запроса или заголовками ответа при передаче множественного содержимого (MIME).
Все необходимые для функционирования HTTP заголовки описаны в основных RFC. При необходимости можно создавать свои заголовки. Традиционно к именам таких дополнительных заголовков добавляют префикс «X-» для избежания конфликта имён с возможно существующими.
Строки после главной строки запроса (GET /index.html HTTP/1.1) имеют следующий формат: Параметр: значение. Таким образом задаются параметры запроса. Это является необязательным, все строки после главной строки запроса могут отсутствовать; в этом случае сервер принимает их значение по умолчанию или по результатам предыдущего запроса (при работе в режиме Connection: Keep-Alive).
Параметр Connection(соединение) — может принимать значения Keep-Alive и close. В HTTP 1.0 за передачей сервером затребованных данных следует разъединение с клиентом, и транзакция считается завершённой, если не передан заголовок Connection: Keep Alive. В HTTP 1.1 сервер по умолчанию не разрывает соединение и клиент может посылать другие запросы. Поскольку во многие документы встроены другие документы — изображения, кадры, апплеты и т.д., это позволяет сэкономить время и затраты клиента, которому в противном случае пришлось бы для получения всего одной страницы многократно соединяться с одним и тем же сервером. Таким образом, в HTTP 1.1 транзакция может циклически повторяться, пока клиент или сервер не закроет соединение явно.
Параметр Accept — список поддерживаемых браузером типов содержимого в порядке их предпочтения данным браузером.
Параметр Host — имя домена, с которого запрашивается ресурс. Полезно, если на сервере имеется несколько виртуальных серверов под одним IP- адресом. В этом случае имя виртуального домена определяется по этому полю.
Параметр Accept-Language определение локали в браузере — поддерживаемый язык. Имеет значение для сервера, который может выдавать один и тот же документ в разных языковых версиях.
Параметр Cache-Control — используется для проверки того, не изменился ли документ; может использоваться как в запросе, так и в ответе, т.е. и клиент, и сервер могут решать, сколько времени будут действительны передаваемые ими документы.
Set-Cookie: name=value — указание браузеру сохранить Cookie. В этом случае, если куки поддерживаются браузером и их приём включён, браузер запоминает строку name=value (имя = значение) и отправляет её обратно серверу с каждым последующим запросом. Браузер при запросе следующей страницы вышлет заголовок Cookie: name=value. Этот запрос отличается от первого запроса тем, что содержит строку, которую сервер отправил браузеру ранее. Таким образом, сервер узнает, что этот запрос связан с предыдущим. Сервер отвечает, отправляя запрашиваемую страницу и, возможно, добавив новые куки. Для избежания межсайтового скриптинга(XSS) нужно устанавливать флаг HttpOnly, который делает cookies недоступными для скриптов со стороны клиента.
Формат ответа также имеет заголовок и тело, разделенное пустой строкой.
Параметр Content-Length (длина содержимого) — длина содержимого ответа в байтах, а не символов. Начало работы с node.js — если тело сообщения содержит многобайтные символы, то необходимо использовать Buffer.byteLength() для определения количества использованных для кодирования байтов, вместо length.
Параметр Transfer-Encoding используется, когда заранее не известен размер данных (Content-Length) в ответе сервера, например для динамически формируемых объектов. В этом случае используется механизм Chunked transfer encoding.
Параметр Last-Modified (модифицирован в последний раз) (W3C Last-Modified) — дата и время последнего изменения документа. Используя его, клиент, подобно случаю с ETag, может обращаться к серверу с запросом ‘If-Modified-Since’ — в этом случае сервер должен сравнить дату последней модификации копии, сохраненной на клиенте, с актуальной датой последней модификации. Если они совпадут, это значит, что копия в кэше клиента не устарела, и повторное скачивание не нужно (код ответа ‘304 Not Modified’). Last-Modified также необходим для корректной обработки сайта роботами, которые используют информацию о дате модификации страниц в целях сортировки результатов поиска по дате, а также для определения частоты обновляемости Вашего сайта.
Для SSI документов Apache будет выдавать «Last-Modified» в том случае, если указана директива «XBitHack full» (например, в файле .htaccess)
Параметр ETag (объектная метка) — появился в HTTP 1.1(W3C ETag). ETag служит для присвоения каждой странице уникального идентификатора, значение которого меняется при изменении страницы (документа). ETag представляет собой хеш («отпечаток») байтов документа, если в документе изменится хоть один байт, то изменится и ETag. ETag используется при кэшировании документа. Этот заголовок сохраняется на клиенте, и в случае повторного обращения к документу позволяет браузеру обратиться к серверу с запросом ‘If-None-Match’, а сервер должен по значению ETag- метки определить, не изменился ли документ(страница), и если нет, ответить кодом ‘304 Not Modified’.
Параметр Expires (истечение)(W3C Expires) — он сообщает браузеру, какой временной промежуток можно считать, что копия страницы в кэше свежа, и вообще не обращаться к серверу с запросами. Это удобно для таких файлов, о которых вы точно знаете, что они не изменятся ближайший час/день/месяц: фоновая картинка страницы, например.
HTTP. Методы, статус-коды, заголовки, редиректы, SSL
Настоящий знает, как работает Интернет. Рассказываем для всех простым языком, как работает HTTP.
Видео
Структура HTTP-запросов и ответов
В HTTP и запрос, и ответ имеют похожую структуру:
- URL
- Метод
- Версия HTTP
- Заголовки
- Статус-код (обязательно только для HTTP-ответов)
- Тело (необязательно)
- POST — метод,
- /cgi-bin/process.cgi — URL,
- HTTP/1.1 — версия протокола HTTP,
- User-Agent , Host и другие — заголовки
- licenseID=string&content=string&/paramsXML=string — тело запроса.
В данном ответе отсутствует URL и метод, зато появился статус-код 200 , означающий «успех».
URL запроса
Структура URL-адреса
- http:// — протокол
- blog — поддомен (субдомен, домен третьего уровня)
- example — домен (домен второго уровня)
- com — доменная зона (домен первого уровня)
- 80 — порт. Для http — 80, для https — 443
- /catalog/category/knifes — ЧПУ-адрес (человеко-понятный URL)
- key1=value1&key2=value2 — GET параметры запроса
- anchor — якорь
Абсолютные и относительные URL
Абсолютные адреса в проекте — зло. Используйте относительные.
Абсолютный URL, скрыт протокол
Относительный URL (неправильно)
Относительный URL (правильно) ✅
Якоря (анкоры) ⚓️
Якоря придуманы в HTML, чтобы давать ссылки не просто на HTML-страницу, а на определенное место на странице. Позже якоря стали активно использоваться для передачи параметров в JS.
HTML-элемент, на который ведет якорь
Методы HTTP-запросов
Если при повторении одного и того же запроса на сервере ничего не меняется, запрос считается идемпотентным. Если повторение одинакового запроса несколько раз изменяет состояние сервера, то он не идемпотентен и, вообще говоря, менее безопасен.
| Метод | POST-параметры | Идемпотентность | Предназначение |
|---|---|---|---|
| GET | нет | да | получает информацию о ресурсе |
| POST | да | нет | создает ресурс |
| PUT | да | да | заменяет ресурс целиком |
| PATCH | да | да | редактирует ресурс |
| DELETE | нет | да | удаляет ресурс |
| HEAD | нет | да | не получает body, только отправляет и получает HTTP-заголовки |
PUT заменяет существующую сущность. Те элементы сущности, которые не представлены в запросе, будут очищены или заменены на null.
GET и POST параметры
В контексте методов HTTP-запросов стоит упомянуть GET и POST параметры, так как вы будете постоянно с ними встречаться и так проще понять, как используются методы.
GET-параметры передаются в URL запроса. Пример URL с GET-параметрами я приводил выше. Любой из перечисленных ниже методов может иметь или не иметь GET-параметры, это совершенно нормально.
POST-параметры — это любые параметры, передаваемые в теле (body) запроса. POST-параметры не следует использовать для некоторых методов, например, для GET, DELETE и HEAD.
Статус-коды ответа
По группам
- 100 — 199 Информационные
- 200 — 299 Успешные
- 300 — 399 Редиректы
- 400 — 499 Клиентские ошибки
- 500 — 599 Серверные ошибки
Популярные коды ответа
- Для редиректов SEO-шники рекомендуют 301 редиректы.
- 401 не авторизован (юзер не представился)
- 403 запрещено (юзер не уполномочен)
- 404 ресурс не найден
- 418 я чайник
- 419 кука протухла (обычно ошибка проверки CSRF)
- 502 Bad Gateway. Программа веб-сервер (Nginx) получила неправильный ответ от бэкенда (PHP). Скорее всего, что-то сломалось или неправильно настроено на сервере
- 504 Gateway Timeout. Программа веб-сервер устала ждать ответа от бэкенда и отменила запрос к нему. Скорее всего, на бэкенде происходит что-то очень долгое, какое-то большое вычисление. Ну и все равно это не нормально, такого быть не должно.
- 503 Maintenance Mode. На сервере ведутся технические работы.
Коды ответа, как и заголовки, можно посмотреть в браузере на вкладке Network или получить командой curl -I domain.ru . В отличие от заголовков, коды ответа бывают только в ответе и не используются в запросе.
Заголовки HTTP
Заголовки — часть HTTP-запроса и/или HTTP-ответа, они не видимы пользователю. Представляют собой пары ключ: значение. Заголовки можно посмотреть в браузере на вкладке Network или получить командой curl -I domain.ru (так можно получить только заголовки ответа сервера).
Заголовки запроса
- Host — ВАЖНО. Домен, по которому мы переходим
- Cookie — куки, отдаваемые браузером серверу
- User-Agent — браузер, которым делаем запрос
- Accept-Language и Accept-Encoding — принимаемые браузером язык и кодировка
- Referer — предыдущая страница
- Authorization — реквизиты для базовой авторизации (логин, пароль)
Заголовки ответа
- Cache-Control — сервер говорит браузеру, как кэшировать данные
- Content-Type — тип и подтип содержимого, а также кодировка и приложение для открытия содержимого. Примеры:
- Content-Type: text/html; charset=UTF-8 — Тип текст, подтип HTML. Кодировка UTF-8
- Content-Type: image/gif — Тип картинка, подтип GIF
- Content-Type: application/pdf — Тип «открываемый внешним приложением», подтип PDF
HTTP-редиректы
Редиректы — способ перенаправить браузер на другой URL. Это похоже на то, как если бы вы пришли в магазин и там увидели надпись «мы переехали, вот наш новый адрес». После этого вы идете в магазин по новому адресу. Важно понимать, что редирект со стороны сайта лишь просит ваш браузер перейти на другой адрес, а не подсовывает вам другую страницу. Другими словами, технически редирект происходит на стороне клиента, а не сервера.
www и http://
Проверка редиректов очень важна для проверки настроек префиксов домена типа www и http / https .
То есть у каждого домена обычно есть 4 варианта написания:
И 3 из этих 4 вариантов обязательно должны ссылаться на один из них, то есть на главный. Главный вариант определяет заказчик, но обычно это https://domain.ru
Инструменты
Редиректы можно проверить браузером через вкладку Network

Разработчикам будет удобнее воспользоваться утилитой
Как сбросить кэш редиректов браузера
На Windows нажать ctrl+H, затем «очистить историю», оставить включенной (отжатой) только галочку напротив «Изображения и другие файлы, сохраненные в кэше». Затем нажать «удалить данные».
SSL шифрование
Принцип — передача только зашифрованных данных.

- Платные (Comodo, Thawte, reg.ru)
- Срок — 1 год или более
- Стоимость — от 1500 руб/год
- Срок — 3 месяца
- Стоимость — бесплатно
- Нюанс: Wild Card сертификаты для поддоменов (*.flagstudio.ru). Доступны в LE только при DNS-аутентификации, то есть добавлении TXT-записи, которую нужно обновлять каждые 3 месяца. Для обновления используется API, которое есть не у всех DNS-провайдеров.
Диагностика SSL
Если на сайте проблемы с SSL, то причина — в одном из двух:
- Что-то не так с сертификатом (кончился, выдан не на этот домен или самоподписанный)
- Страница запрашивает что-то по HTTP

На скриншоте видно, как посмотреть подробности о сертификате и наличие ошибок в странице. Конкретно на этом скриншоте показана вторая проблема, так называемая «mixed-content error», то есть часть контента прилетает по HTTP.
Для диагности SSL на вашем сайте вы также можете использовать онлайн-сервис https://www.ssllabs.com/ssltest/ .
Учтите, данные о сертификате, как и HTTP-редиректы, сильно кэшируются браузером. Сбрасываются так же, как кэш редиректов (смотрите выше).Версии HTTP
HTTP/2
Суть — мультиплексирование запросов по TCP.
Преимущества перед HTTP/1.1
- Скорость. HTTP/2 — бинарный протокол, а HTTP/1.1 — текстовый
- Скорость. Мультиплексирование множества запросов в одном соединении TCP
- Скорость. Сжатие HTTP-заголовков
- Server Push. Принудительная отправка данных сервером в браузер
- Приоритеты запросов
- Из-за «head-of-line blocking» на медленном интернете HTTP/1.1 работает быстрее
- Для работы HTTP/2 нужен SSL
Распространение: По данным W3Techs на 1 ноября 2020 года, 49% из 10 млн самых популярных интернет-сайтов поддерживают протокол HTTP/2.
HTTP/3
Суть — мультиплексирование по UDP.
Преимущества перед HTTP/2:
- Решена проблема «head-of-line blocking»
- Шифрование и транспорт объединены, пакеты шифруются независимо
- Протокол реализуется на уровне приложений, а не ОС. Поэтому быстро внедряется
- Протокол реализуется на уровне приложений, а не ОС. Поэтому HTTP/3 использует больше CPU
Результаты: По данным Google, страницы загружаются примерно на 5% быстрее, а в потоковом видео на 30% меньше подвисаний по сравнению с TCP.
Распространение: По данным W3Techs на 1 сентября 2020 года, 7% из 10 млн самых популярных интернет-сайтов поддерживают протокол HTTP/3.
Если у вас появились какие-то вопросы, вы можете задать их в комментариях, а мы на них ответим
HTTP: протокол, который каждый разработчик должен знать (часть 1)
HTTP — это протокол передачи гипертекста между распределёнными системами. По сути, http является фундаментальным элементом современного Web-а. Как уважающие себя веб разработчики, мы должны знать о нём как можно больше.
Давайте взглянем на этот протокол через призму нашей профессии. В первой части пройдёмся по основам, посмотрим на запросы/ответы. В следующей статье разберём уже более детальные фишки, такие как кэширование, обработка подключения и аутентификация.
Также в этой статье я буду, в основном, ссылаться на стандарт RFC 2616: Hypertext Transfer Protocol — HTTP/1.1.
Основы HTTP
HTTP обеспечивает общение между множеством хостов и клиентов, а также поддерживает целый ряд сетевых настроек.
В основном, для общения используется TCP/IP, но это не единственный возможный вариант. По умолчанию, TCP/IP использует порт 80, но можно заюзать и другие.

Общение между хостом и клиентом происходит в два этапа: запрос и ответ. Клиент формирует HTTP запрос, в ответ на который сервер даёт ответ (сообщение). Чуть позже, мы более подробно рассмотрим эту схему работы.
Текущая версия протокола HTTP — 1.1, в которой были введены некоторые новые фишки. На мой взгляд, самые важные из них это: поддержка постоянно открытого соединения, новый механизм передачи данных chunked transfer encoding, новые заголовки для кэширования. Что-то из этого мы рассмотрим во второй части данной статьи.
Сердцевиной веб-общения является запрос, который отправляется через Единый указатель ресурсов (URL). Я уверен, что вы уже знаете, что такое URL адрес, однако для полноты картины, решил всё-таки сказать пару слов. Структура URL очень проста и состоит из следующих компонентов:

Протокол может быть как http для обычных соединений, так и https для более безопасного обмена данными. Порт по умолчанию — 80. Далее следует путь к ресурсу на сервере и цепочка параметров.
Методы
С помощью URL, мы определяем точное название хоста, с которым хотим общаться, однако какое действие нам нужно совершить, можно сообщить только с помощью HTTP метода. Конечно же существует несколько видов действий, которые мы можем совершить. В HTTP реализованы самые нужные, подходящие под нужды большинства приложений.
GET: получить доступ к существующему ресурсу. В URL перечислена вся необходимая информация, чтобы сервер смог найти и вернуть в качестве ответа искомый ресурс.
POST: используется для создания нового ресурса. POST запрос обычно содержит в себе всю нужную информацию для создания нового ресурса.
PUT: обновить текущий ресурс. PUT запрос содержит обновляемые данные.
DELETE: служит для удаления существующего ресурса.
Данные методы самые популярные и чаще всего используются различными инструментами и фрэймворками. В некоторых случаях, PUT и DELETE запросы отправляются посредством отправки POST, в содержании которого указано действие, которое нужно совершить с ресурсом: создать, обновить или удалить.
Также HTTP поддерживает и другие методы:
HEAD: аналогичен GET. Разница в том, что при данном виде запроса не передаётся сообщение. Сервер получает только заголовки. Используется, к примеру, для того чтобы определить, был ли изменён ресурс.
TRACE: во время передачи запрос проходит через множество точек доступа и прокси серверов, каждый из которых вносит свою информацию: IP, DNS. С помощью данного метода, можно увидеть всю промежуточную информацию.
OPTIONS: используется для определения возможностей сервера, его параметров и конфигурации для конкретного ресурса.
Коды состояния
В ответ на запрос от клиента, сервер отправляет ответ, который содержит, в том числе, и код состояния. Данный код несёт в себе особый смысл для того, чтобы клиент мог отчётливей понять, как интерпретировать ответ:
1xx: Информационные сообщения
Набор этих кодов был введён в HTTP/1.1. Сервер может отправить запрос вида: Expect: 100-continue, что означает, что клиент ещё отправляет оставшуюся часть запроса. Клиенты, работающие с HTTP/1.0 игнорируют данные заголовки.
2xx: Сообщения об успехе
Если клиент получил код из серии 2xx, то запрос ушёл успешно. Самый распространённый вариант — это 200 OK. При GET запросе, сервер отправляет ответ в теле сообщения. Также существуют и другие возможные ответы:
- 202 Accepted: запрос принят, но может не содержать ресурс в ответе. Это полезно для асинхронных запросов на стороне сервера. Сервер определяет, отправить ресурс или нет.
- 204 No Content: в теле ответа нет сообщения.
- 205 Reset Content: указание серверу о сбросе представления документа.
- 206 Partial Content: ответ содержит только часть контента. В дополнительных заголовках определяется общая длина контента и другая инфа.
3xx: Перенаправление
Своеобразное сообщение клиенту о необходимости совершить ещё одно действие. Самый распространённый вариант применения: перенаправить клиент на другой адрес.
- 301 Moved Permanently: ресурс теперь можно найти по другому URL адресу.
- 303 See Other: ресурс временно можно найти по другому URL адресу. Заголовок Location содержит временный URL.
- 304 Not Modified: сервер определяет, что ресурс не был изменён и клиенту нужно задействовать закэшированную версию ответа. Для проверки идентичности информации используется ETag (хэш Сущности — Enttity Tag);
4xx: Клиентские ошибки
Данный класс сообщений используется сервером, если он решил, что запрос был отправлен с ошибкой. Наиболее распространённый код: 404 Not Found. Это означает, что ресурс не найден на сервере. Другие возможные коды:
- 400 Bad Request: вопрос был сформирован неверно.
- 401 Unauthorized: для совершения запроса нужна аутентификация. Информация передаётся через заголовок Authorization.
- 403 Forbidden: сервер не открыл доступ к ресурсу.
- 405 Method Not Allowed: неверный HTTP метод был задействован для того, чтобы получить доступ к ресурсу.
- 409 Conflict: сервер не может до конца обработать запрос, т.к. пытается изменить более новую версию ресурса. Это часто происходит при PUT запросах.
5xx: Ошибки сервера
Ряд кодов, которые используются для определения ошибки сервера при обработке запроса. Самый распространённый: 500 Internal Server Error. Другие варианты:
- 501 Not Implemented: сервер не поддерживает запрашиваемую функциональность.
- 503 Service Unavailable: это может случиться, если на сервере произошла ошибка или он перегружен. Обычно в этом случае, сервер не отвечает, а время, данное на ответ, истекает.
Форматы сообщений запроса/ответа
На следующем изображении вы можете увидеть схематично оформленный процесс отправки запроса клиентом, обработка и отправка ответа сервером.

Давайте посмотрим на структуру передаваемого сообщения через HTTP:
Между заголовком и телом сообщения должна обязательно присутствовать пустая строка. Заголовков может быть несколько:
Тело ответа может содержать полную информацию или её часть, если активирована соответствующая возможность (Transfer-Encoding: chunked). HTTP/1.1 также поддерживает заголовок Transfer-Encoding.
Общие заголовки
Вот несколько видов заголовков, которые используются как в запросах, так и в ответах:
Что-то мы уже рассмотрели в этой статье, что-то подробней затронем во второй части.
Заголовок via используется в запросе типа TRACE, и обновляется всеми прокси-серверами.
Заголовок Pragma используется для перечисления собственных заголовков. К примеру, Pragma: no-cache — это то же самое, что Cache-Control: no-cache. Подробнее об этом поговорим во второй части.
Заголовок Date используется для хранения даты и времени запроса/ответа.
Заголовок Upgrade используется для изменения протокола.
Transfer-Encoding предназначается для разделения ответа на несколько фрагментов с помощью Transfer-Encoding: chunked. Это нововведение версии HTTP/1.1.
Заголовки сущностей
В заголовках сущностей передаётся мета-информация контента:
Все заголовки с префиксом Content- предоставляют информацию о структуре, кодировке и размере тела сообщения.
Заголовок Expires содержит время и дату истечения сущности. Значение “never expires” означает время + 1 код с текущего момента. Last-Modified содержит время и дату последнего изменения сущности.
С помощью данных заголовков, можно задать нужную для ваших задач информацию.
Формат запроса
Запрос выглядит примерно так:
SP — это разделитель между токенами. Версия HTTP указывается в HTTP-Version. Реальный запрос выглядит так:
Список возможных заголовков запроса:
В заголовке Accept определяется поддерживаемые mime типы, язык, кодировку символов. Заголовки From, Host, Referer и User-Agent содержат информацию о клиенте. Префиксы If- предназначены для создания условий. Если условие не прошло, то возникнет ошибка 304 Not Modified.
Формат ответа
Формат ответа отличается только статусом и рядом заголовков. Статус выглядит так:
- HTTP версия
- Код статуса
- Сообщение статуса, понятное для человека
Обычный статус выглядит примерно так:
Заголовки ответа могут быть следующими:
- Age время в секундах, когда сообщение было создано на сервере.
- ETag MD5 сущности для проверки изменений и модификаций ответа.
- Location используется для перенаправления и содержит новый URL адрес.
- Server определяет сервер, где было сформирован ответ.
Думаю, на сегодня теории достаточно. Теперь давайте взглянем на инструменты, которыми мы можем пользоваться для мониторинга HTTP сообщений.
Инструменты для определения HTTP трафика
Существует множество инструментов для мониторинга HTTP трафика. Вот несколько из них:
Наиболее часто используемый — это Chrome Developers Tools:

Если говорить об отладчике, можно воспользоваться Fiddler:

Для отслеживания HTTP трафика вам потребуется curl, tcpdump и tshark.
Библиотеки для работы с HTTP — jQuery AJAX
Поскольку jQuery очень популярен, в нём также есть инструментарий для обработки HTTP ответов при AJAX запросах. Информацию о jQuery.ajax(settings) можете найти на официальном сайте.
Передав объект настроек (settings), а также воспользовавшись функцией обратного вызова beforeSend, мы можем задать заголовки запроса, с помощью метода setRequestHeader().
Прочитать объект jqXHR можно с помощью метода jqXHR.getResponseHeader().
Если хотите обработать статус запроса, то это можно сделать так:
Вот такой вот он, тур по основам протокола HTTP. Во второй части будет ещё больше интересных фактов и примеров.
5 последних уроков рубрики «Разное»
Как выбрать хороший хостинг для своего сайта?
Выбрать хороший хостинг для своего сайта достаточно сложная задача. Особенно сейчас, когда на рынке услуг хостинга действует несколько сотен игроков с очень привлекательными предложениями. Хорошим вариантом является лидер рейтинга Хостинг Ниндзя — Макхост.
Как разместить свой сайт на хостинге? Правильно выбранный хороший хостинг — это будущее Ваших сайтов
Проект готов, Все проверено на локальном сервере OpenServer и можно переносить сайт на хостинг. Вот только какую компанию выбрать? Предлагаю рассмотреть хостинг fornex.com. Отличное место для твоего проекта с перспективами бурного роста.
Разработка веб-сайтов с помощью онлайн платформы Wrike
Создание вебсайта — процесс трудоёмкий, требующий слаженного взаимодействия между заказчиком и исполнителем, а также между всеми членами коллектива, вовлечёнными в проект. И в этом очень хорошее подспорье окажет онлайн платформа Wrike.
20 ресурсов для прототипирования
Подборка из нескольких десятков ресурсов для создания мокапов и прототипов.
Топ 10 бесплатных хостингов
Небольшая подборка провайдеров бесплатного хостинга с подробным описанием.







