Заголовки HTTP: кеш, CORS, cookie, безопасность

Заголовки — пары «имя: значение» перед телом запроса и ответа. Имена не зависят от регистра: Content-Type и content-type одно и то же, а в HTTP/2 и HTTP/3 они вообще передаются строчными буквами. Ниже те, с которыми приходится иметь дело чаще всего.

Запрос: кто, что и в каком виде хочет

Числа q=0.8 в Accept-* — веса от 0 до 1, по умолчанию 1. Accept: text/html, application/json;q=0.9, */*;q=0.1 означает: лучше HTML, потом JSON, в крайнем случае что угодно.

Authorization

Строку Basic можно раскодировать любым декодером Base64, поэтому такая схема допустима только поверх HTTPS. Содержимое JWT-токена показывает разбор JWT.

Ответ: что и как отдано

Частые значения Content-Type:

Кодировки и почему в charset должно стоять utf-8, разобраны в статье про UTF-8, а процентное кодирование из формы можно проверить в URL-кодировщике.

Кеширование

Главный заголовок — Cache-Control. Его директивы комбинируются через запятую.

Удобная схема для сайта:

# HTML: всегда спрашивать, не изменилось ли
Cache-Control: no-cache

# Стили и скрипты с хешем в имени: app.3f9a2c.js
Cache-Control: public, max-age=31536000, immutable

Проверка свежести: ETag и Last-Modified

Сервер отдаёт «версию» ресурса:

HTTP/1.1 200 OK
ETag: "33a64df5"
Last-Modified: Tue, 14 Oct 2026 08:00:00 GMT
Cache-Control: no-cache

В следующий раз браузер спрашивает условно:

GET /app.css HTTP/1.1
If-None-Match: "33a64df5"

Если ресурс не поменялся, сервер отвечает 304 Not Modified без тела, и трафик экономится. ETag обычно считают хешем содержимого; приставка W/ означает «слабый» ETag, который допускает несущественные отличия.

Vary

Vary: Accept-Encoding говорит кешам, что ответ зависит от этого заголовка запроса и для каждого его значения нужна своя копия. Без него кеш может отдать сжатый ответ клиенту, который не понимает сжатие. Vary: Cookie или Vary: Authorization фактически делают ответ личным для каждого пользователя.

CORS

Браузер не даёт скрипту со страницы одного источника читать ответы другого источника. Источник — это схема, домен и порт вместе: app.local:3000 и api.local:8080 разные. CORS — способ серверу сказать браузеру, что такое чтение разрешено.

Простой запрос (GET или POST с обычными заголовками) браузер отправляет сразу, а потом смотрит на ответ:

Access-Control-Allow-Origin: <точное значение Origin из запроса>

Сервер повторяет источник из заголовка Origin запроса целиком, вместе со схемой и портом, если этот источник есть в его списке разрешённых. Значение * разрешает любой источник, но не работает вместе с cookie и авторизацией.

Если запрос «непростой» — метод PUT или DELETE, заголовок Authorization, Content-Type: application/json — браузер сначала отправляет предварительный запрос OPTIONS:

Cookie

Сервер выдаёт cookie заголовком Set-Cookie, по одному заголовку на каждую:

Set-Cookie: sid=a1b2c3; Path=/; Max-Age=2592000; HttpOnly; Secure; SameSite=Lax

Для сессионной cookie разумный минимум: HttpOnly; Secure; SameSite=Lax. Префикс имени __Host- дополнительно требует Secure, Path=/ и отсутствие Domain, и браузер не примет такую cookie, если условие не выполнено.

Заголовки безопасности

Эти заголовки стоит отдавать на любом сайте. Их проще всего задать один раз в настройках веб-сервера.

Пример строгой политики CSP для сайта без внешних ресурсов:

Content-Security-Policy: default-src 'self'; img-src 'self' data:; style-src 'self';
  script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'

frame-ancestors 'none' в CSP — современная замена X-Frame-Options: DENY. Политику удобно сначала включить в режиме наблюдения через заголовок Content-Security-Policy-Report-Only: браузер будет писать нарушения в консоль, ничего не ломая.

Как посмотреть заголовки

curl -I localhost:8080/                 # только заголовки ответа, методом HEAD
curl -sv localhost:8080/ -o /dev/null   # заголовки запроса и ответа
curl -s -D - localhost:8080/ -o /dev/null

В браузере заголовки видны во вкладке «Сеть»: выберите запрос, раздел «Заголовки». Подробнее о запросах из терминала в шпаргалке по curl.