Для чего используются HTTP заголовки и примеры
Что проверяют
Понимаете ли вы, что заголовки управляют кэшем, авторизацией, CORS и безопасностью, то есть напрямую касаются фронтенда. Перечислить пять имён мало. Следом обычно спрашивают про CORS или про разницу no-cache и no-store.
Как отвечать
Заголовки это метаданные запроса и ответа в виде пар «имя: значение». Имена нечувствительны к регистру, в HTTP/2 и HTTP/3 они передаются в нижнем регистре и сжимаются. Удобнее всего отвечать группами:
- содержимое:
Content-Typeговорит, как читать тело,Acceptпросит нужный формат,Accept-EncodingиContent-Encodingдоговариваются о сжатииbrилиgzip; - кэширование:
Cache-Control: max-age=31536000, immutableдля статики с хешем в имени;no-cacheзначит «храни, но перепроверяй»,no-storeзначит «не храни вообще».ETagсIf-None-Matchдают ответ304 Not Modifiedбез тела; - авторизация и состояние:
Authorization: Bearer <token>,CookieиSet-Cookieс флагамиHttpOnly,Secure,SameSite; - CORS: браузер шлёт
Origin, сервер отвечаетAccess-Control-Allow-Origin. Нестандартный заголовок илиContent-Type: application/jsonвызывают предварительный запросOPTIONS; - безопасность:
Content-Security-Policy,Strict-Transport-Security,X-Content-Type-Options: nosniff,Referrer-Policy.
С фронтенда заголовки задаются в fetch(url, { headers }) и читаются через response.headers.get('etag'). Часть заголовков браузер выставить не даст (Cookie, Host, Origin), а при кросс-доменном запросе JS видит только безопасный набор заголовков ответа плюс перечисленные в Access-Control-Expose-Headers.
Где спотыкаются
Думают, что no-cache запрещает кэширование. Он требует перепроверки, а запрет это no-store.
Руками ставят Content-Type: multipart/form-data при отправке FormData. Пропадает boundary, и сервер не может разобрать тело. Этот заголовок нужно оставить браузеру.
Считают CORS защитой сервера и пытаются «починить» его на клиенте. Ограничение применяет браузер, а разрешение даёт только сервер. Кроме того, с credentials: 'include' значение * в Access-Control-Allow-Origin не работает.