Re: proxy_set_header и наследие

Vladimir Getmanshchuk vladget на gmail.com
Пт Мар 24 13:32:41 UTC 2017


Hi!

2017-03-23 19:00 GMT+02:00 Maxim Dounin <mdounin на mdounin.ru>:

> Hello!
>

Спасибо за скорый и развернутый ответ.


> Документация о таком поведение - явно говорит,
> http://nginx.org/ru/docs/http/ngx_http_proxy_module.html#proxy_set_header:
>
> : Директивы наследуются с предыдущего уровня при условии, что на
> : данном уровне не описаны свои директивы proxy_set_header.
>
> Не стоит удивляться такому поведению.  Вместо этого - стоит его
> понять и пользоваться преимуществами.
>

Читал.


>
> > 2) Если делаешь proxy_set_header дважды (иногда пересекается из-за
> > include), то получаешь два хедера в HTTP запросе(от чего некоторые
> backends
> > сходят с ума, когда видят два хедера Host(например).
> > Почему не брать значение из последнего proxy_set_header?
>
> В HTTP вполне допустимо использование нескольких одинаковых
> заголовков, более того - явно специфицировано, когда можно, а
> когда - нельзя, и как трактовать.  И во многих случаях это
> используется.
>
> Было бы странно ограничивать людей в том, что они могут написать в
> конфиге, причём совсем не так, как специфицирует используемый
> протокол.
>

А какое из значений двух хедеров "Host" будет использовать NGINX для
определения server_name?


>
> > Поймите правильно, не хочется писать proxy_set_header в каждом (вложенном
> > тоже?) локейшене, а использовать наследие.
>
> Не пишите, кто же вас заставляет.
>
> В случае правильно и грамотно написанной конфигурации - обычно
> хватает одного набора директив proxy_set_header на уровне http,
> возможно - с отдельными вкраплениями "специальных" наборов.
>

Так и есть, но у меня меняется хедер Host на некоторых locations,
что-бы отправить "сквозной" запрос на нужный мне микросервис внутри бэкэнда,
без использования "прослойки"..


> Если очень нужно вносить локальные изменения в конкретных
> location'ах - можно использовать директиву include с неким базовым
> набором, дополняя его по необходимости.  Но если вы регулярно
> сталкиваетесь с подобной проблемой - скорее всего вы что-то
> делаете не так.
>

Так и решил, но выглядет не очень кошерно...

-- 
Yours sincerely,
Vladimir Getmanshchuk
----------- следущая часть -----------
Вложение в формате HTML было извлечено…
URL: <http://mailman.nginx.org/pipermail/nginx-ru/attachments/20170324/6ea55127/attachment.html>


Подробная информация о списке рассылки nginx-ru