Зачем проверять наличие заголовков в HTTP ответе

Что проверяют

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

Как отвечать

Разложите по задачам, где заголовки влияют на фронтенд:

• формат: перед response.json() стоит проверить Content-Type. Прокси или балансировщик при сбое нередко отдают HTML-страницу, иногда даже с кодом 200, и вместо понятной ошибки вы получаете SyntaxError при разборе;
• кэширование: Cache-Control, ETag, Last-Modified. Статика с хэшем в имени отдаётся с max-age=31536000, immutable, а index.html с no-cache, иначе после релиза пользователь получает старую страницу со ссылками на удалённые чанки;
• CORS: Access-Control-Allow-Origin и связанные с ним заголовки решают, отдаст ли браузер ответ вашему коду;
• безопасность: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options: nosniff, флаги HttpOnly, Secure, SameSite в Set-Cookie;
• служебные данные: общее число записей для пагинации, Retry-After при 429, имя файла в Content-Disposition, Location после создания ресурса.

Проверяют их в трёх местах: в DevTools при отладке, в коде через response.headers.get() и в автотестах, которые фиксируют, что политика кэширования или CSP не сломалась после правки конфигурации сервера.

Где спотыкаются

Не знают про Access-Control-Expose-Headers. При кросс-доменном запросе JavaScript видит только короткий список безопасных заголовков вроде Content-Type и Cache-Control. Свой X-Total-Count вернётся как null, пока сервер явно его не откроет, хотя в Network он виден.

Пытаются прочитать Set-Cookie из fetch. Браузер этот заголовок скрипту не отдаёт, а куки с HttpOnly вообще недоступны из JavaScript. Это защита, а не баг.

Советуют устаревшее: X-XSS-Protection современные браузеры не поддерживают, а вместо X-Frame-Options сейчас рекомендуют директиву frame-ancestors в CSP.