Как в Nginx добавить заголовки в определённом location (для ответа API)?

Question

[asakasinsky]

Исходные данные:

server {
    ... 
    location / {
        ...
    }
    location /api/v1/ {
        ...
    }
    location ~ "^(.+\.php)($|/)" {
        ...
    }
}

Объявим заголовок , например:
add_header 'X-my-api-header' 'bla-bla-bla';

Требуется добавить этот заголовок для генерируемого api json или xml в location /api/v1/ .

Если заголовок добавить до описания правил для location, заголовок появляется, но для всего ресурса. Если его добавить для location api или location /, заголовок отсутствует в ответе сервера, но появляется если поместить заголовок в location php. Тогда заголовок появляется во всех ответах запросов к php-скриптам.

Так как API отдаёт данные в запрашиваемых форматах, пытался объявить заголовок для этих форматов, но тщетно. Возможно это происходит потому что выдачу данных генерирует php-скрипт. До этой задачки наивно полагал что знаю как работают настройки location.

Comments

[Евгений]

Почему нельзя из php добавить заголовок?

[asakasinsky]

Мне нужно инициировать CORS для определённых locations. А это в простейшем виде «add_header 'Access-Control-Allow-Origin' "*";», что и является добавлением заголовка. PHP и отдаёт этот заголовок на данный момент.

Меня интересует возможность сделать это посредством nginx для лучшего понимания его работы. Танцы это или извращения, но поскольку в nginx заложена сама возможность работы с locations, значит эту возможность можно и нужно использовать.

Answer 1

[Евгений]

У вас одна точка входа у приложения?

Comments

[asakasinsky]

Не совсем. На одном сервере несколько версий одного и того же приложения. Отсюда и locations с разными названиями версий. Плюс в корне — небольшая админка.

[Евгений]

Тогда можно так
location ~ "^/api/v1/(.+\.php)($|/)" { ... }

[Евгений]

дело в том, что nginx всегда сначала регулярки обрабатывает

[asakasinsky]

Да, как раз пришёл к такому решению. И обнаружил еще нюанс, что разместить это надо перед обработчиком корневого location. Вот что получилось в итоге https://gist.github.com/asakasinsky/7873740

[asakasinsky]

«дело в том, что nginx всегда сначала регулярки обрабатывает», в nginx.org/ru/docs/http/request_processing.html говорится следующее:

«…nginx вначале ищет среди всех префиксных location’ов, заданных строками, максимально совпадающий. В вышеприведённой конфигурации указан только один префиксный location “/”, и поскольку он подходит под любой запрос, он и будет использован, если других совпадений не будет найдено. Затем nginx проверяет location’ы, заданные регулярными выражениями, в порядке их следования в конфигурационном файле. При первом же совпадении поиск прекращается и nginx использует совпавший location. Если запросу не соответствует ни одно из регулярных выражений, nginx использует максимально совпавший префиксный location, найденный ранее…»

[Алексей Сундуков]

@Nc_Soft не стоит в сети увеличивать количество лжи. nginx в первую очередь отработает префиксные location и только потом регулярные. Причем вне зависимости от того, в какой последовательности они идут в конфигурационном файле. Более того, модификатором = можно его заставить не проверять дальше регулярные location вовсе.

[Евгений]

А если проверить?
server {
listen 80;
server_name test.local;
location /alekciy {
deny all;
}
location ~* ^.+\.(jpg|jpeg|gif|png)$ {
root /home/test;
}
}
что-то я не вижу 403 надписи по ссылке test.local/alekciy/lie.jpg

[asakasinsky]

@Nc_Soft и я не вижу. Есть картинка. Чёрт, я реально сбит с толку, благородный сир. Тем лучше — когда разберусь, это в памяти отложится. Я нашёл несколько разъясняющих тем, но они все говорят об обратном. Пример на SO: stackoverflow.com/questions/5238377/nginx-location...

[Евгений]

Ахаха, а еще спрайт прозрачный!
В какой-то презентации помню Сысоев говорил что регулярки первыми идут.

[asakasinsky]

@Nc_Soft, @alekciy Я нашёл истину (-:, она — тут: nginx.org/ru/docs/http/ngx_http_core_module.html#l...

[asakasinsky]

Если быть кратким, то вся суть вот: действительно, сначала проверяются все префиксные location, наиболее подходящий запоминается, проверяются все регулярные, и если ни один регулярный location не подошёл, используется префиксный, что был запомнен ранее.

[asakasinsky]

@Nc_Soft и теперь я понимаю почему нет 403 заголовка (-:

[Евгений]

А если я сформулирую это так, что сначала проверяются регулярки, то суть от этого меняется?
Вообше, лучше чтараться избегать регулярок вообще, а если очень надо, то заворачивать локейшен с ними в другой локейшен.

[Евгений]

Советую посмотреть video.yandex.ru/users/ibondarets/view/1

[asakasinsky]

Ну, если интересно моё мнение, то оно выражается в отсутствии фанатизма. Иногда можно съесть и немытое яблоко. Идея очень здравая, но иногда невыполнимая, например, при переносе какой-либо ЦМС на VDS/VPS, когда желание поправить код чтобы отделить статику никем не оплачивается, а уговаривать не хочется. Это я про регулярки. А про суть, то да, она не меняется, но механизм работы неверно представляется.

[asakasinsky]

За ссылку на видео доклада спасибо преогромнейшее. И вообще спасибо за диалог. Я редко задаю вопросы, и тут сомневался задавать ли, ведь всё и так работает. И не пожалел. Для меня очень информативно получилось.

Answer 2

[Алексей Сундуков]

Мне кажется подход изначально архитектурно неправильный.

api json или xml

За данными как я понимаю все равно нужно ходить к PHP. Так зачем эти танцы с location? Отправляйте на обработку в php все запросы, скрипте по расширению файла добавлять соотвествующий http header.

Comments

[asakasinsky]

Я дополнил вопрос

Answer 3

[justabaka]

Если 1 location, то можно if'ом, если нет опасений, что if is evil, как-то так:

if ($uri ~ ^/api/v1/.*){
add_header 'X-my-api-header' 'bla-bla-bla';
}

Если можно наплодить сколько угодно локейшенов, то копируем уже имеющийся в /api/v1/, настраиваем аналогично имеющемуся (fastcgi_pass и все такое) и добавляем заголовок.

А вообще, проще ставить заголовок силами PHP, чем заниматься таким извращением.

Comments

[asakasinsky]

Я дополнил вопрос

Answer 4

[Дэн Иванов]

Вероятно в location /api/v1/ у вас прописано что то вроде

if (!-e $request_filename) {
rewrite ^.*$ /index.php last;
}

Поэтому запрос и уходит в location ~ "^(.+\.php)($|/)"
Если я правильно понимаю задачу, то вам нужно для ответов бэкенда с content-type json / xml проставлять соответсвующий хедер.
Здесь может помочь проверка хедера Content-type в ответе сервера.
Получить его можно через переменные upstream модуля: $upstream_http_$HEADER. Тоесть в вашем случае это будет выглядеть как $upstream_http_content_type.
А далее если вам нужно кастомное значение загловка для каждого типа контента, применить map, как то так:

map $upstream_http_content_type $type {
default "custom_header_default";
"application/json" "custom_header_json";
"text/xml" "custom_header_xml";
}

Сам такое ни разу не делал, поэтому отвечаю только "теоретически", как это может работать.

Comments

[asakasinsky]

1. Да, кстати, похоже проблема с rerwrite. Проверю и отпишу. 2.Нет, цель - CORS для определённых locations. Я дополнил вопрос.

[Дэн Иванов]

В таком случае этот вариант тоже подходит, просто переменную type заполняете чем нужно, и ее уже подставляете в качестве значения в add_header

[asakasinsky]

А ведь точно (-:

[Дэн Иванов]

Поидее как то так:

http {
...
    map $upstream_http_content_type $origin {
    default "*";
    "application/json" "origin_allowed_json";
    "text/xml" "origin_allowed_xml";
...
}

server {
...
    location ~ "^(.+\.php)($|/)" {
    ...
        add_header 'Access-Control-Allow-Origin' "$origin";
    ...
    }
}

[asakasinsky]

Всегда получаю «default "*";». На досуге поломаю голову почему (-:

[asakasinsky]

А задача решена

[koller18]

asakasinsky, не подскажите как? если помните))