Работа с HTTP-заголовками запроса и ответа в Angie
HTTP-заголовки сопровождают каждый обмен данными между клиентом и сервером. Они описывают параметры запроса и ответа, определяют формат содержимого, участвуют в управлении кэшем, повышают безопасность и помогают находить ошибки при диагностике веб-приложений. Поэтому настройка HTTP-заголовков - важная часть конфигурации современного веб-сервера.
В этой статье разберём, как сервер Angie формирует стандартные заголовки, каким образом добавлять собственные значения и как изменять заголовки при проксировании запросов. Практические HTTP заголовки примеры помогут понять, какие директивы использовать в типичных сценариях.
Заголовки ответа, которые формирует Angie
Часть заголовков Angie добавляет автоматически. Одни из них необходимы для корректной обработки HTTP-протокола, другие включаются по умолчанию для удобства клиентов и администраторов.
Например, заголовок `Server` сообщает название веб-сервера и, в стандартной конфигурации, его версию. Управлять детализацией этого значения позволяет директива `server_tokens`. В открытой версии Angie с её помощью можно скрыть номер версии. Вариант с параметром `build` дополнительно показывает сведения о сборке. В Angie PRO разрешено задать произвольное значение заголовка либо полностью убрать его, указав пустую строку.
Для статических ресурсов сервер обычно формирует заголовок `ETag`. Он используется браузерами и промежуточными узлами при проверке актуальности сохранённой копии файла. Если применение ETag не требуется, его можно отключить директивой `etag off;`. Сведения о дате формирования ответа передаются через стандартный заголовок `Date`.
Особое значение имеет `Content-Type`. Браузер ориентируется на него, когда решает, как обработать полученные данные: показать изображение, открыть HTML-документ, воспроизвести мультимедиа или предложить загрузку файла. Для статических объектов тип определяется по расширению на основании файла `mime.types`, обычно расположенного в `/etc/angie/mime.types`.
Если необходимого расширения в таблице нет, соответствующую запись можно добавить вручную. Когда определить тип не удаётся, Angie использует значение, заданное директивой `default_type`. При неподходящем типе браузер нередко воспринимает ответ как неизвестный файл и предлагает сохранить его на диск вместо отображения в окне.
Кодировка содержимого и Content-Type
В `Content-Type` может передаваться не только тип данных, но и кодировка. Для управления ею применяется стандартный модуль Charset. Наиболее распространённый вариант - указать UTF-8:
```nginx
charset utf-8;
```
После этого сервер добавит параметр кодировки в HTTP-ответ. Angie также поддерживает преобразование данных между кодировками. Исходный набор символов задаётся с помощью `source_charset`, а целевой - через `charset`.
Для проксируемых ответов автоматическая перекодировка по умолчанию не выполняется. При необходимости её можно включить отдельной директивой. Такой механизм полезен, если старое внутреннее приложение возвращает данные в нестандартной кодировке, а внешним клиентам требуется UTF-8.
Добавление собственных заголовков
Для пользовательских заголовков ответа используется модуль `Headers` и директива `add_header`. Например:
```nginx
location / {
add_header X-Application "catalog";
}
```
В этом случае Angie добавит `X-Application` к ответам указанного контекста. Директива поддерживает дополнительный параметр `always`, который позволяет отправлять заголовок не только при успешном ответе, но и при ошибках:
```nginx
add_header X-Request-Policy "strict" always;
```
Это особенно важно для защитных параметров: заголовки безопасности должны присутствовать не только на страницах с кодом `200`, но и на ответах `4xx` или `5xx`.
Правила наследования требуют внимания. Если на текущем уровне объявлен хотя бы один `add_header`, набор директив из родительского контекста может перестать применяться. Поэтому при разделении настроек между блоками `http`, `server` и `location` следует проверять итоговую конфигурацию, чтобы случайно не потерять важный заголовок.
Практическая настройка HTTP-заголовков часто включает защитные значения:
```nginx
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "SAMEORIGIN" always;
```
Подробный разбор возможностей Angie и работы с заголовками доступен в материале о [HTTP-заголовках запроса и ответа](https://habr.com/ru/articles/1074772/?utm_campaign=1074772&utm_source=habrahabr&utm_medium=rss).
Изменение и удаление заголовков
Стандартный модуль подходит для добавления новых значений, но не всегда позволяет заменить или удалить уже существующий заголовок. Такая необходимость возникает, например, при проксировании: внутреннее приложение может отправлять служебные данные, которые не следует показывать клиенту.
Для более гибкой работы применяется модуль `Headers-More`. С его помощью можно переопределять значения, удалять заголовки и управлять ими в разных контекстах. Это удобно при построении единой политики для нескольких приложений, работающих за обратным прокси.
К примеру, при публикации сервисов через единый домен можно скрыть внутренний заголовок:
```nginx
more_clear_headers "X-Powered-By";
```
Или задать единое значение:
```nginx
more_set_headers "X-Frame-Options: SAMEORIGIN";
```
Перед применением таких директив необходимо убедиться, что используемая сборка Angie содержит соответствующий модуль.
Заголовки при работе с Proxy
При проксировании Angie передаёт запрос внутреннему серверу и формирует собственный набор заголовков. На практике часто настраивают `Host`, `X-Real-IP`, `X-Forwarded-For` и `X-Forwarded-Proto`, чтобы приложение знало исходный адрес клиента, схему подключения и запрошенный домен:
```nginx
location /api/ {
proxy_pass http://backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
```
Без этих параметров приложение может считать, что все пользователи приходят с адреса прокси, а HTTPS-запросы воспринимать как обычные HTTP-соединения. Это приводит к ошибкам в редиректах, формировании абсолютных URL и работе механизмов аудита.
Заголовки ответа от upstream-сервера также можно изменять. Для этого применяются директивы `proxy_hide_header`, `proxy_set_header` и возможности модуля `Headers-More`. Нужно учитывать, что некоторые заголовки имеют особое значение: например, некорректное изменение `Content-Length`, `Transfer-Encoding` или `Connection` способно нарушить передачу ответа.
Заголовки безопасности и кэширование
Тема "HTTP-заголовки безопасность сайта" включает несколько разных задач. Защита от встраивания страницы регулируется `Content-Security-Policy` и `X-Frame-Options`, запрет MIME-сниффинга - `X-Content-Type-Options`, а управление политикой передачи URL - `Referrer-Policy`. При использовании HTTPS стоит рассмотреть `Strict-Transport-Security`, но включать его следует только после проверки всей инфраструктуры.
Кэширование HTTP-заголовков также требует аккуратной настройки. Директивы `Cache-Control`, `Expires`, `ETag` и `Last-Modified` определяют, может ли браузер повторно использовать сохранённый ответ и должен ли он проверять актуальность ресурса. Для версионируемых статических файлов допустим длительный кэш, тогда как персональные страницы и ответы API обычно требуют запрета хранения или короткого времени жизни.
Проверять результат удобно с помощью `curl`:
```bash
curl -I https://example.com/
```
Команда показывает заголовки без загрузки тела ответа. Для диагностики прокси полезно сравнивать внешний ответ с тем, что возвращает backend напрямую. Так можно обнаружить потерянные значения, неожиданные дубли или неправильное наследование директив.
Итоги
HTTP-заголовки связывают клиент, Angie и внутренние приложения в единую цепочку обмена данными. Через них задаются тип и кодировка содержимого, правила кэширования, параметры безопасности, сведения о клиенте и особенности проксирования.
Начинать настройку стоит с минимального набора: корректного `Content-Type`, безопасной передачи IP-адресов, понятной политики кэширования и базовых защитных заголовков. Затем конфигурацию можно расширять с помощью `add_header`, `Headers-More` и директив Proxy. При этом важно проверять заголовки не только для успешных ответов, но и для ошибок, редиректов и ответов, полученных от upstream-серверов.
