Для чего используются HTTP заголовки и примеры

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

Понимаете ли вы, что заголовки управляют поведением HTTP: форматом тела, кэшем, авторизацией, CORS. Для Java-разработчика следом обычно идёт вопрос, как прочитать и выставить заголовок в Spring и какие заголовки безопасности добавляет Spring Security.

Как отвечать

Заголовки это метаданные запроса и ответа в виде пар «имя: значение». Имена нечувствительны к регистру, в HTTP/2 и HTTP/3 они передаются в нижнем регистре. Примеры лучше группировать по задачам:

• формат тела: Content-Type говорит, что лежит в теле (application/json), Accept говорит, что клиент готов принять. В Spring на них завязаны consumes и produces у @RequestMapping, при несовпадении получите 415 или 406;
• авторизация: Authorization: Bearer <token>, без учётных данных сервер отдаёт 401 и WWW-Authenticate;
• кэш: Cache-Control, ETag и If-None-Match. Совпал ETag, и сервер отвечает 304 без тела;
• CORS: браузер шлёт Origin, для непростых запросов делает preflight OPTIONS, сервер отвечает Access-Control-Allow-Origin и соседними заголовками;
• служебные: Location при 201 Created, Retry-After при 429 и 503, traceparent для распределённой трассировки;
• безопасность: Strict-Transport-Security, X-Content-Type-Options: nosniff, X-Frame-Options, Content-Security-Policy. Часть из них Spring Security ставит по умолчанию.

В коде: @RequestHeader("X-Request-Id") String id в контроллере, HttpServletRequest.getHeader(), для ответа ResponseEntity.ok().header(...) или объект HttpHeaders. Сквозные заголовки вроде идентификатора запроса удобно проставлять в фильтре (OncePerRequestFilter) и класть в MDC для логов.

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

Путают Content-Type и Accept и не могут объяснить, откуда взялся 415 на POST с JSON.

Считают CORS защитой сервера. Это правило браузера: curl или другой бэкенд заголовки CORS игнорируют, поэтому авторизацию он не заменяет.

Пишут в логи все заголовки подряд, включая Authorization и Cookie. Токены и сессии утекают в систему логов, такие поля нужно маскировать.