Re: Наследование директив proxy_hide_header и proxy_pass_header

2023-07-24 Пенетрантность Maxim Dounin
Hello!

On Mon, Jul 24, 2023 at 06:42:14PM +0300, Gena Makhomed wrote:

> Здравствуйте, All!
> 
> Наследование директив proxy_hide_header и proxy_pass_header
> не работает ожидаемым образом, nginx 1.25.1
> конфиг:
> 
> http {
> 
>  proxy_pass_header Content-Disposition;
> 
>  server {
> 
>  server_name sentry.example.com;
> 
>  location / {
>  proxy_hide_header Content-Disposition;
>  proxy_pass http://172.17.110.100:9000;
>  }
>  }
> }
> 
> Директива proxy_hide_header не работает в такой конфигурации,
> - заголовок Content-Disposition присутствует в ответе сервера.
> 
> Если закомментировать директиву proxy_pass_header
>   на уровне http - только после этого начинает нормально
> работать директива proxy_hide_header на уровне location.
> 
> Это ошибка в коде nginx, что наследование не работает ожидаемым образом,
> или это ошибка в документации к nginx, что это явно не оговорено,
> или же это ошибка в моем понимании документации nginx?

Насколько я вижу, каких-либо специальных условий наследования для 
proxy_pass_header и proxy_hide_header в документации не указано.  
Соответственно, по общему правилу это два разных списка и они 
наследуются независимо:

- список заголовков, которые нужно спрятать, определяется 
  директивами proxy_hide_header; список наследуется с предыдущего 
  уровня, если на текущем уровне не определены директивы 
  proxy_hide_header.

- список спрятанных заголовков, которые тем не менее нужно 
  передать клиенту, определяется директивами proxy_pass_header;
  список наследуется с предыдущего уровня, если на текущем уровне 
  не определены директивы proxy_pass_header.

Наблюдаемое поведение, насколько я вижу, ожидаемому соответствует: 
в случае наличия заголовка в списке proxy_pass_header он 
передаётся клиенту, в случае отсутствия (и наличия в списке 
proxy_hide_header) - не передаётся.

> Задача у меня такая - надо включить заголовок Content-Disposition
> для всех сайтов, за исключением одного сайта - sentry self-hosted,
> для того чтобы обойти баг, который присутствует в браузере Safari.
> 
> Если я что-то делаю неправильно - как правильно решить эту задачу?
> 
> Подробнее об этом баге в браузере Safari и о workaround, для него:
> 
> https://github.com/getsentry/self-hosted/issues/2285#issuecomment-1647664859

Заголовок Content-Disposition отсутствует в proxy_hide_header по 
умолчанию, так что для решения данной задачи будет достаточно 
указать "proxy_hide_header Content-Disposition;" в конфигурации 
проксирования для Sentry.  Как, собственно, и предлагают по 
ссылке.

-- 
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru


Наследование директив proxy_hide_header и proxy_pass_header

2023-07-24 Пенетрантность Gena Makhomed

Здравствуйте, All!

Наследование директив proxy_hide_header и proxy_pass_header
не работает ожидаемым образом, nginx 1.25.1
конфиг:

http {

proxy_pass_header Content-Disposition;

server {

server_name sentry.example.com;

location / {
proxy_hide_header Content-Disposition;
proxy_pass http://172.17.110.100:9000;
}
}
}

Директива proxy_hide_header не работает в такой конфигурации,
- заголовок Content-Disposition присутствует в ответе сервера.

Если закомментировать директиву proxy_pass_header
 на уровне http - только после этого начинает нормально
работать директива proxy_hide_header на уровне location.

Это ошибка в коде nginx, что наследование не работает ожидаемым образом,
или это ошибка в документации к nginx, что это явно не оговорено,
или же это ошибка в моем понимании документации nginx?

Задача у меня такая - надо включить заголовок Content-Disposition
для всех сайтов, за исключением одного сайта - sentry self-hosted,
для того чтобы обойти баг, который присутствует в браузере Safari.

Если я что-то делаю неправильно - как правильно решить эту задачу?

Подробнее об этом баге в браузере Safari и о workaround, для него:

https://github.com/getsentry/self-hosted/issues/2285#issuecomment-1647664859

--
Best regards,
 Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-ru


Re: Наследование директив установки заголовков

2018-01-02 Пенетрантность gz
> Вместо копирования надо использовать include

Для 3-5 общих и пары заголовков уровнем ниже, include — это перебор.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277956,277971#msg-277971

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив установки заголовков

2018-01-02 Пенетрантность Konstantin Tokarev


02.01.2018, 19:43, "gz" :
> Ясно, решение политическое.
> Благодарю за пояснение.
>
>>  Вам не нужно просматривая все уровни вложенности и в уме суммировать
>
> списки директив.
>
> Эта необходимость, кстати, никуда не девается.
> И если при обычном наследовании достаточно просмотреть 2-3 уровня (вложенные
> location'ы в расчёт не берём) и сложить, то при текущем выборочном — нужно
> просматривать те же уровни, только для того, чтобы проверить не указаны ли
> там уже директивы и, если это так, скопировать их.

Вместо копирования надо использовать include

>
> Posted at Nginx Forum: 
> https://forum.nginx.org/read.php?21,277956,277967#msg-277967
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

-- 
Regards,
Konstantin
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив установки заголовков

2018-01-02 Пенетрантность gz
Ясно, решение политическое.
Благодарю за пояснение.

> Вам не нужно просматривая все уровни вложенности и в уме суммировать
списки директив.

Эта необходимость, кстати, никуда не девается.
И если при обычном наследовании достаточно просмотреть 2-3 уровня (вложенные
location'ы в расчёт не берём) и сложить, то при текущем выборочном — нужно
просматривать те же уровни, только для того, чтобы проверить не указаны ли
там уже директивы и, если это так, скопировать их.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277956,277967#msg-277967

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив установки заголовков

2018-01-01 Пенетрантность Валентин Бартенев
On Monday, 1 January 2018 07:34:48 MSK gz wrote:
> Знатоки, поясните пожалуйста, с какой целью в nginx сделано так, что
> add_header и proxy_set_header «наследуются с предыдущего уровня при условии,
> что на данном уровне не описаны свои директивы»?
> 
> Это же ужасно неудобно — хочется задать ряд общих заголовков на уровне
> http/server, а в location'ах добавлять отдельные заголовки.
> Стоит прозевать и установить единственный заголовок в location'е —
> отваливаются все вышеустановленные.
> 
> Наверное, у такого решения есть большие преимущества, но прояснить их для
> себя не могу.
> 

 1. Это не отличается от всех остальных директив в nginx, т.е. это единое
правило, делающее конфигурацию единообразной.

При этом, если раньше какую-то директиву можно было задать только один
раз, а позже стало возможным описывать несколько таких директив, то
существующие конфигурации от этого не ломаются, ибо правило наследования,
что у одной директивы, что у нескольких - одниковое.

 2. А про остальное рассказывает Игорь:
https://www.youtube.com/watch?v=fcG-7k20oG8

Если кратко, это делает конфигурацию однозначной.  Работает ровно то,
что видите в конкретном блоке.  Вам не нужно просматривая все уровни
вложенности и в уме суммировать списки директив.

--
Валентин Бартенев
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Наследование директив установки заголовков

2017-12-31 Пенетрантность gz
Знатоки, поясните пожалуйста, с какой целью в nginx сделано так, что
add_header и proxy_set_header «наследуются с предыдущего уровня при условии,
что на данном уровне не описаны свои директивы»?

Это же ужасно неудобно — хочется задать ряд общих заголовков на уровне
http/server, а в location'ах добавлять отдельные заголовки.
Стоит прозевать и установить единственный заголовок в location'е —
отваливаются все вышеустановленные.

Наверное, у такого решения есть большие преимущества, но прояснить их для
себя не могу.

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,277956,277956#msg-277956

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-16 Пенетрантность igor.goncharenko
Спасибо!

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,275849,276074#msg-276074

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-15 Пенетрантность Maxim Dounin
Hello!

On Tue, Aug 15, 2017 at 04:19:41AM -0400, igor.goncharenko wrote:

> Вопрос, наверное, был о том - нужно ли переназначать ВСЕ proxy_ директивы на
> данном уровне (как для заголовков) или наследование работает для каждой
> proxy_ директивы отдельно?

Не надо думать, что для заголовков действуют какие-то особые 
правила.  Наоборот, тут действует простое общее правило: значение, 
заданое конкретной директивой, наследуется с предыдущего уровня, 
если на данном уровне эта директива не используется.

Соответственно, если вы использовали на данном уровне директиву 
proxy_set_header - то заданные на предыдущих уровнях заголовки 
наследоваться не будут (а если не использовали - будут).  
Аналогично и для proxy_read_timeout - если она на данном уровне 
используется, то наследования не будет, а если нет - то будет 
наследоваться значения с предыдущего уровня.  И то же самое для 
практически всех директив.

Исключения бывают, но они редки и при этом очевидны.  Скажем, 
директивы allow и deny задают список правил, и указание любой из 
них приводит к отмене наследования всего списка правил.  А 
некоторые директивы не наследуются, как то: try_files, инструкции 
модуля rewrite (rewrite, if, set, break, return), директивы, 
устанавливающие обработчики в конкретном location'е (proxy_pass, 
fastcgi_pass, scgi_pass, uwsgi_pass, memcached_pass, flv, mp4, 
empty_gif, stub_status).  И это наверное всё, если говорить про 
исключния, для всего остального - действует общее правило.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-15 Пенетрантность igor.goncharenko
Вопрос, наверное, был о том - нужно ли переназначать ВСЕ proxy_ директивы на
данном уровне (как для заголовков) или наследование работает для каждой
proxy_ директивы отдельно?


---
Igor

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,275849,276065#msg-276065

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-07 Пенетрантность Maxim Dounin
Hello!

On Mon, Aug 07, 2017 at 08:32:24AM -0400, marston.lorenz wrote:

> А что насчёт наследования директив ?

С наследованием директив действует общее правило: значение 
наследуется с предыдущего уровня, если оно не преопределено на 
данном уровне.

-- 
Maxim Dounin
http://nginx.org/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-07 Пенетрантность marston.lorenz
С форматом time без указание единиц понятно.

А что насчёт наследования директив ?

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,275849,275896#msg-275896

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-04 Пенетрантность Sargas
 >http://nginx.org/ru/docs/syntax.html
Значение без суффикса задаёт секунды

4 августа 2017 г., 16:06 пользователь Maxim K  написал:

> Также не понятно
>
>> В каких единицах по умолчанию задаёться время таймаута если явно не
>> указывать формат:
>>
>> proxy_read_timeout 100;  не понятно
>> proxy_read_timeout 100s;  100 секунд
>>
>
> http://nginx.org/ru/docs/syntax.html
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-04 Пенетрантность Maxim K
Также не понятно

> В каких единицах по умолчанию задаёться время таймаута если явно не
> указывать формат:
>
> proxy_read_timeout 100;  не понятно
> proxy_read_timeout 100s;  100 секунд
>

http://nginx.org/ru/docs/syntax.html
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Наследование директив

2017-08-04 Пенетрантность marston.lorenz
Также не понятно
В каких единицах по умолчанию задаёться время таймаута если явно не
указывать формат:

proxy_read_timeout 100;  не понятно
proxy_read_timeout 100s;  100 секунд

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,275849,275851#msg-275851

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Наследование директив

2017-08-04 Пенетрантность marston.lorenz
Подскажите пожалуйста, как происходит наследование директив:
proxy_read_timeout
proxy_connect_timeout
proxy_send_timeout
client_header_timeout

В основном конфиге вписаны переопределённые параметры для этих директив,
но при этом один Я получаю отлуп по значению по умолчанию (60 секунд), хотя
все переопределённые timeout сильно отличны от значений по умолчанию.

Хочу понять как происходит наследование для локейшеном этих параметров

Posted at Nginx Forum: 
https://forum.nginx.org/read.php?21,275849,275849#msg-275849

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru