Levels's

HTTP-заголовки

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

  1. Метод HTTP, глагол (например, GET, PUT или POST) или существительное (например, HEAD или OPTIONS), описывающие требуемое действие. Например, GET указывает, что нужно доставить некоторый ресурс, а POST означает отправку данных на сервер (для создания или модификации ресурса, или генерации возвращаемого документа).
  2. Цель запроса, обычно URL, или абсолютный путь протокола, порт и домен обычно характеризуются контекстом запроса. Формат цели запроса зависит от используемого HTTP-метода. Это может быть
    • Абсолютный путь, за которым следует '?' и строка запроса. Это самая распространённая форма, называемая исходной формой (origin form) . Используется с методами GET, POST, HEAD, и OPTIONS. POST / HTTP 1.1 GET /background.png HTTP/1.0 HEAD /test.html?query=alibaba HTTP/1.1 OPTIONS /anypage.html HTTP/1.0
    • Полный URL — абсолютная форма (absolute form) , обычно используется с GET при подключении к прокси. GET http://developer.mozilla.org/ru/docs/Web/HTTP/Messages HTTP/1.1
    • Компонента URL «authority», состоящая из имени домена и (необязательно) порта (предваряемого символом ':'), называется authority form. Используется только с методом CONNECT при установке туннеля HTTP. CONNECT developer.mozilla.org:80 HTTP/1.1
    • Форма звёздочки (asterisk form), просто «звёздочка» ('*') используется с методом OPTIONS и представляет сервер. OPTIONS * HTTP/1.1
  3. Версия HTTP, определяющая структуру оставшегося сообщения, указывая, какую версию предполагается использовать для ответа.

Заголовки носят служебный характер. В них указывается информация для корректной работы системы.

Заголовки разделяются на 4 типа:

  • Заголовки запросов (Request headers)
  • Заголовки ответов (Response headers)
  • Основные заголовки (General headers)
  • Заголовки сущности (Entity headers)

Request headers используются при отправке запроса на сервер. Служат для передачи дополнительной, уточняющей и служебной информации. Некоторые заголовки, например, User-Agent, отправляются только в request headers.

npx playwright --version
import { test, expect } from '@playwright/test';

test('has title', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Expect a title "to contain" a substring.
  await expect(page).toHaveTitle(/Playwright/);
});

test('get started link', async ({ page }) => {
  await page.goto('https://playwright.dev/');

  // Click the get started link.
  await page.getByRole('link', { name: 'Get started' }).click();

  // Expects page to have a heading with the name of Installation.
  await expect(page.getByRole('heading', { name: 'Installation' })).toBeVisible();
});

Response headers используются при отправке ответа от сервера к клиенту. Также служат для передачи дополнительной, уточняющей и служебной информации. Некоторые заголовки могут быть отправлены только в response headers. Например, Set-cookie, которые сервер генерирует и отправляет клиенту для того, чтобы клиент сохранил данные куки и при последующих запросах присылал их для идентификации и аналитических целей.

В группу General headers входят такие заголовки, как Date, Connection и т.п. Данная группа заголовков не описывает содержимое запроса и является общей для клиента и сервера.

В группу Entity headers входят заголовки, служащие для описания содержимого запросов. Entity headers отправляются вместе с request headers или response headers. Большинство entity headers начинаются с Content-. Например:

  • Content-Length
  • Content-Language
  • Content-Type
  • Content-Location
  • Link и т.д.

На практике, как правило, разделяют запросы на request headers и response headers.

Заголовки представляют из себя набор ключей и значений key: value. Давайте разберем некоторые распространенные заголовки.

User-Agent

User-Agent — этот заголовок отправляет серверу информацию о том, с какого устройства или браузера осуществляется запрос.

Пример заголовка User-Agent:

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36.

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

Host

Host — данный заголовок указывает, к какому конкретному веб-сайту на HTTP-сервере следует обратиться. На одном сервере может быть размещено множество различных веб-сайтов, и заголовок Host помогает серверу определить, к какому из них обращается запрос. В качестве значений для этого заголовка могут выступать как доменные имена, так и IP-адреса. Стоит отметить, что заголовок Host является обязательным для HTTP версии 1.1 и выше.

Примеры заголовка Host:

  • Host: www.youtube.com
  • Host: localhost:8000

Referer и Referrer-policy

Referer — данный заголовок используется для указания источника, откуда был отправлен текущий запрос. Если, например, пользователь кликнет на логотип Stepik в верхнем левом углу какой-либо страницы, переходя на главную, к запросу будет добавлен заголовок вида Referer: https://stepik.com/lesson....

Referrer-policy — этот заголовок определяет, какой именно информацией заполнять заголовок Referer. Это может быть, например, только URL или полный URI. Этот заголовок важен с точки зрения безопасности и конфиденциальности, так как позволяет контролировать, какие данные и в каких обстоятельствах будут передаваться в Referer.

Если говорить простыми словами, Referrer-policy диктует, какие данные и в каких случаях должны передаваться в Referer.

Примеры заголовка Referrer-policy:

  • Referrer-Policy: no-referrer — заголовок Referer не указывается
  • Referrer-Policy: no-referrer-when-downgrade — заголовок Referer не указывается при переходе с HTTPS на HTTP
  • Referrer-Policy: origin — в  Referer указывается только URL
  • Referrer-Policy: origin-when-cross-origin — при переходах внутри одного ресурса по HTTPS в Referer указывается URI. В иных случаях — только URL.
  • Referrer-Policy: same-origin — при переходах внутри одного ресурса в Referer указывается URI. При переходах на другой ресурс Referer не передается. 
  • Referrer-Policy: strict-origin — при переходах с HTTPS на HTTP Referer не передается. В ином случае передается URL.
  • Referrer-Policy: strict-origin-when-cross-origin — при переходах внутри одного ресурса по HTTPS передается URI. При переходах по HTTPS на сторонние ресурсы — передается URL. При переходе на сторонний ресурс с HTTPS на HTTP — Referer не передается.
  • Referrer-Policy: unsafe-url — всегда передается URI, вне зависимости от безопасности ресурса.

Accept

Accept— заголовок, который позволяет клиенту указать, какие типы медиафайлов он может принять и обработать. В данном заголовке могут быть указаны несколько типов, перечисленные через запятую.

Примеры заголовка Accept:

  • Accept: */* — клиент может принять и обработать любой формат.
  • Accept: text/html — клиент может принять и обработать только формат HTML
  • Accept: text/html, application/json — клиент может принять и обработать формат HTML и JSON

В заголовке Accept может быть любое значение из типов MIME.

Authorization

Authorization— Используется для идентификации пользователя. Является уникальным для каждого пользователя, выдается системой после успешной идентификации пользователя. Хранится на стороне клиента и отправляется серверу для аутентификации. Бывают разные способы аутентификации.

Пример заголовка Authorization:

  • Authorization: Bearer 12iDASnf_dsASk32...

Set-Cookie

Set-Cookie — Сервер генерирует куки и отправляет их клиенту чтобы клиент хранил их и отправлял при последующих запросах. Куки передаются в формате name=value. 

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

Пример заголовка Set-Cookie:

  • Set-Cookie: NIm=NOvTiKlzkb_PPzaFOwA40FxDY8_3qtOKZhY;
  • Set-Cookie: csrftoken=un151mMlOp38;

У заголовка Set-Cookie, существуют атрибуты служащие для управления куками. Рассмотрим распространенные атрибуты:

  • Expires=<дата и время> — устанавливает максимальную дату и время жизни куки.
  • Max-Age=<кол-во секунд> — устанавливает максимальное время жизни кук в секундах. Имеет приоритет перед Expires.
  • Domain=<доменное имя> — указывает на какой хост должны отправляться куки.
  • Path=</эндпоинт> — указывает по какому эндпоинту должны отправляться куки. Если значение Path=/, значит куки отправляются по всем эндпоинтам.
  • Secure — означает, что куки могут отправляться только на ресурс использующий защищеный протокол HTTPS.
  • HttpOnly — предназначен для защиты от кражи кук вредоносным скриптом JavaScript. Блокирует доступ JavaScript к кукам. 
  • SameSite=Strict — куки передаются только при переходах внутри одного и того же ресурса. Например: если vk.com отправил нам куки с данным атрибутом, и мы переходим с google.com на vk.com, то при этом переходе куки не будут отправлены. Но при последующих переходах внутри vk.com куки будут прилагаться к запросам.
  • SameSite=Lax — куки передаются при межсайтовых переходах по прямой ссылке. Например, если переходим с google.com на vk.com, куки будут отправлены. Отличие атрибута SameSite=Lax в том, что куки отправляются только при переходе по прямой ссылке. Так, если с google.com в разделе «картинки» мы скачиваем картинку с другого сайта, куки передаваться не будут. В случае отсутствия атрибута SameSite, по умолчанию с 2019 года применяется значение SameSite=Lax.
  • SameSite=None; Secure — данный атрибут снимает ограничения по передаче куки. Данный атрибут может передаваться только по защищенному протоколу HTTPS и с атрибутом Secure, который мы рассматривали выше.

Примеры заголовка Set-Cookie с атрибутами:

  • Set-Cookie: NIm=NOvTiKlzkb_PPzaFOwA40FxDY8_3qtOKZhY; SameSite=None; Secure
  • Set-Cookie: csrftoken=un151mMlOp38; Max-Age=360000; SameSite=Strict; Domain=vk.com; HttpOnly

Примечание 1.
Куки отправленные сервером без атрибута Expires или Max-Age — являются сессионными и существуют во время текущей сессии, пока открыт браузер.

Примечание 2.
Куки в которых присутствует атрибут Expires или Max-Age — являются постоянными.

Cookie

Cookie — данный заголовок используется клиентом для отправки серверу кук, полученных через Set-Cookie. Заголовок содержит в себе одну или несколько пар в формате name=value. Пары кук разделяются символом ;.

Пример заголовка Cookie:

  • Cookie: NIm=NOvTiKlzkb_PPzaFOwA40FxDY8_3qtOKZhY; csrftoken=un151mMlOp38;

Ссылка на документацию по кукам.

Content-Type

Сontent-Type — используется для информирования о формате содержимого body, отправляемого на сервер или получаемого от сервера.

Примеры заголовка Content-Type:

  • Content-Type: application/json
  • Content-Type: application/xml
  • Content-Type: application/x-www-form-urlencoded
  • Content-Type: text/html

В заголовке Content-Type может быть любое значение из типов MIME.

Cache-Control

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

Существует множество видов кэшей. Спецификация HTTP 1.1, ради безопасности и конфиденциальности, разделяет кэши на две группы: общие (Shared) и необщие (Non-Shared).

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

Необщий (или приватный) кэш — это кэш, доступ к которому имеет только один пользователь, например, кэш браузера.

В протоколе HTTP существует несколько заголовков, предназначенных для управления кэшированием:

  1. Cache-Control — ключевой и основной заголовок для управления кэшем. Появился в версии HTTP 1.1 и имеет приоритет перед Expires и Pragma.
  2. Expires — предшественник Cache-Control. Он менее гибкий и, в основном, используется для обратной совместимости со старыми браузерами.
  3. Pragma — устаревший заголовок, который уже редко используется в современных приложениях.

Заголовок Cache-Control является общим (General header). Управление кэшированием с его помощью происходит как при запросах со стороны клиента, так и при ответах со стороны сервера.

Распространенные атрибуты Cache-Control, в клиентских запросах:

  • max-age=<секунды> — клиент готов принять ответ, который можно закэшировать на указанное время.
  • max-stale=<секунды> — клиент готов принять устаревший ответ, в котором время устаревания не превышает указанное количество секунд. Данный атрибут может быть полезен когда сервер не доступен.
  • min-fresh=<секунды> — клиент готов принять ответ, который будет актуальным указанное кол-во секунд.
  • no-cache — перед использованием закэшированных данных, кэш должен проверить актуальность на сервере.
  • no-store — запрет на кэширование каких-либо данных о запросе и ответе.
  • no-transform — запрет на преобразование(конвертацию) данных на стороне кэша.
  • only-if-cached — клиент готов получить любую закэшированную информацию. Данный атрибут может быть полезен, когда сервер не доступен.

Распространенные атрибуты Cache-Control, в ответах от сервера:

  • public — данные можно закэшировать в любом кэше (в общем кэше и кэше браузера).
  • private — данные можно закэшировать только в приватном кэше(в кэше браузера).
  • max-age=<секунды>— сервер указывает, на какое время кэшируются данные с момента создания ответа. По сути данным атрибутом, сервер обозначает срок свежести закэшированных данных. Обратите внимание, что время кэширования начинается не с момента получения, а с момента создания контента.
  • s-max-age — аналогичен max-age, за исключением того, что предназначен для общих кэшей. Если присутствуют одновременно оба атрибута, max-age — будет определять время свежести в кэше браузера, а s-max-age — будет определять время свежести в общем кэше.
  • no-cache — перед использованием закэшированных данных, кэш должен проверить актуальность на сервере.
  • no-store — запрет на кэширование каких-либо данных о запросе и ответе.
  • no-transform — запрет на преобразование(конвертацию) данных на стороне кэша.
  • must-revalidate — после истечения срока свежести, кэш обязан проверить актуальность данных у сервера.
  • proxy-revalidate — аналогичен предыдущему, за исключением того, что распространяется на общие кэши.

Обратите внимание на отличия no-store от no-cache. no-store — запрещает кэшировать запросы и ответы, а no-cache — указывает кэшу, что перед тем, как ответить клиенту, он должен сначала обратиться к серверу и убедиться, что информация не поменялась. 

Так же, про отличия no-cache от must-revalidate. В случае с no-cache, кэш каждый раз обращается к серверу, даже если срок свежести не истек. В случае с must-revalidate, кэш должен обратиться к серверу только после того, как истек срок свежести. 

Connection

Connection — служит для управления соединением между клиентом и сервером.

Примеры заголовка Connection:

  • Connection: keep-alive — соединение между клиентом и сервером не прерывается.
  • Connection: close — говорит о том, что сервер или клиент хотят прекратить связь.

Accept-Language

Accept-Language представляет информацию о языке, которому отдаёт предпочтение пользователь.

Пример заголовка Accept-Language:

  • Accept-Language: ru-RU, ru, en-US, en — система выберет язык в порядке убывания. Сначала система попробует отобразить информацию на русском языке. Если не удастся, предоставит информацию на английском языке. Если и на английском языке не удастся, в этом случае предоставит язык, установленный по умолчанию.

________________________________________________________________________________________________________________________________________

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

Также хочу обратить внимание, что Content-Type используется не для выбора формата ответа, а лишь для информирования о том, в каком формате был направлен запрос или получен ответ. Для выбора формата используется хедер Accept.