Re: переменные $1
День добрый.
23.04.2020 0:35, Slawa Olhovchenkov пишет:
On Thu, Apr 23, 2020 at 12:03:16AM +0300, Maxim Dounin wrote:
Ну да, одно из возможных решений - отучить регулярные выражения в
map'е трогать $1..$N. С другой стороны - конфигурации вида
map $uri $foo {
~(.+) $1;
}
тоже никто не отменял.
не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.
Тут есть два нюанса:
1. Механизм формирования $1..$N - общий, и если map не трогает
$1..$N - то конструкция выше работать не будет. А делать так,
чтобы $1..$N использовали результат выполнения конкретного
регулярного выражения, а не просто последнего - логично как раз в
рамках rewrite'а, где это конкретное регулярное выражение
очевидно. (Ну то есть в рамках map'а следом тоже встанет вопрос,
когда в правой части будет $bar$1, где $bar - ещё один map с
регулярным выражением. Но это, очевидно, надо будет решать так
же.)
2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
быть должны, те же именованные captures - вполне логично
использовать и много кто использует на практике. Использовать
побочные эффекты в виде $1..$N - с моей точки зрения странно, но
теоретически и это вполне может быть.
я понимаю откуда взялось.
что не отменяет гемороя.
https://trac.nginx.org/nginx/ticket/564
Patches are welcome.
6 лет...
Да, за 6 лет никто не сподобился даже попытаться прислать патч.
Что как бы позволяет предложить, что - не жмёт.
или никто не может разобраться.
Это не "или", это именно что "не жмёт". Затраты на попытаться
разобраться - превышают количество проблем, которые создаёт
текущее поведение.
ну хоть бы в документацию большими буквами.
я не получил большого гемороя только из-за того что в процессе у меня
и так полный дебаг был включен по другому поводу и я сразу увидел
такой фифект.
А что, кроме лени, мешает не пользоваться $1$2$3 вообще, а использовать
1. поименованные переменные (?...)
$uniqvar
2. везде, где переменные не нужны или не использовать скобки, а если не
возможно или не удобно, использовать отказ от создания переменной (?:...) ?
и тогда точно будем знать что
map $... {
~^start(?)end$ '1';
}
location /(?.+)/$ {
rewrite ^(?:.+)$ /$mapvar/$locvar/? break;
приведет к тому, что хочется.
нет ?
/А
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: proxy_store и ranges
Hello! On Wed, Apr 22, 2020 at 07:35:55PM +0300, Slawa Olhovchenkov wrote: > А что происходит если у нас есть proxy_store а исходный запрос -- с > ranges? > Скачиваем и сохраняем все, отдаем кусок? > Скачиваем и сохраняем кусок а потом глючим? Директива proxy_store не предполагает собственной логики кроме собственно сохранения ответов. При это сохраняются только ответы с кодом 200. Соответственно если бекенд возвращает 206 (Partial content), то ответ сохранён не будет. Если нужно, чтобы ответ всегда сохранялся - заголовок Range можно убрать из запроса на бекенд с помощью директивы proxy_set_header. Если при этом хочется ещё и вернуть клиенту ответ с учётом запрошенных диапазонов, то в простых случаях это можно сделать, включив директиву proxy_force_ranges. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
Hello!
On Wed, Apr 22, 2020 at 07:14:05PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > А это нормально что переменные $1..$N не являются локальными для
> > > > > регэкспа?
> > > > >
> > > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > > браться из map.
> > > > > Что-то мне кажется это не логично.
> > > >
> > > > Это следствие того, что regexp и использование $1..$N могут быть
> > > > разнесены, например, в конструкциях вида (цитата из
> > > > http://nginx.org/r/if):
> > > >
> > > > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > > set $id $1;
> > > > }
> > > >
> > > > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > > > даже есть тикет:
> > >
> > > не для rewrite, а для map.
> > > вроде как логично ожидать, что map срабатывает выдавая указанную
> > > переменную без каких-либо дополнительных побочных эффектов.
> >
> > Ну да, одно из возможных решений - отучить регулярные выражения в
> > map'е трогать $1..$N. С другой стороны - конфигурации вида
> >
> > map $uri $foo {
> > ~(.+) $1;
> > }
> >
> > тоже никто не отменял.
>
> не понимаю возражения.
> я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
> других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
> $foo сформировался и никому ничего больше от этого map не требуется.
Тут есть два нюанса:
1. Механизм формирования $1..$N - общий, и если map не трогает
$1..$N - то конструкция выше работать не будет. А делать так,
чтобы $1..$N использовали результат выполнения конкретного
регулярного выражения, а не просто последнего - логично как раз в
рамках rewrite'а, где это конкретное регулярное выражение
очевидно. (Ну то есть в рамках map'а следом тоже встанет вопрос,
когда в правой части будет $bar$1, где $bar - ещё один map с
регулярным выражением. Но это, очевидно, надо будет решать так
же.)
2. Вообще говоря, побочные эффекты от регулярных выражений в map'е
быть должны, те же именованные captures - вполне логично
использовать и много кто использует на практике. Использовать
побочные эффекты в виде $1..$N - с моей точки зрения странно, но
теоретически и это вполне может быть.
> > > > https://trac.nginx.org/nginx/ticket/564
> > > >
> > > > Patches are welcome.
> > >
> > > 6 лет...
> >
> > Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> > Что как бы позволяет предложить, что - не жмёт.
>
> или никто не может разобраться.
Это не "или", это именно что "не жмёт". Затраты на попытаться
разобраться - превышают количество проблем, которые создаёт
текущее поведение.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
proxy_store и ranges
А что происходит если у нас есть proxy_store а исходный запрос -- с ranges? Скачиваем и сохраняем все, отдаем кусок? Скачиваем и сохраняем кусок а потом глючим? ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
On Wed, Apr 22, 2020 at 06:59:21PM +0300, Maxim Dounin wrote:
> Hello!
>
> On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
>
> > On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> >
> > > Hello!
> > >
> > > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> > >
> > > > А это нормально что переменные $1..$N не являются локальными для
> > > > регэкспа?
> > > >
> > > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > > результате используется еще и результат map с регэкспом, то $1 будет
> > > > браться из map.
> > > > Что-то мне кажется это не логично.
> > >
> > > Это следствие того, что regexp и использование $1..$N могут быть
> > > разнесены, например, в конструкциях вида (цитата из
> > > http://nginx.org/r/if):
> > >
> > > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > > set $id $1;
> > > }
> > >
> > > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > > даже есть тикет:
> >
> > не для rewrite, а для map.
> > вроде как логично ожидать, что map срабатывает выдавая указанную
> > переменную без каких-либо дополнительных побочных эффектов.
>
> Ну да, одно из возможных решений - отучить регулярные выражения в
> map'е трогать $1..$N. С другой стороны - конфигурации вида
>
> map $uri $foo {
> ~(.+) $1;
> }
>
> тоже никто не отменял.
не понимаю возражения.
я как раз о том, что внури map $1..$N локальные и не портят $1..$N в
других местах. очевидно же, что вот этот $1 _вне_ map никому не нужен.
$foo сформировался и никому ничего больше от этого map не требуется.
> > > https://trac.nginx.org/nginx/ticket/564
> > >
> > > Patches are welcome.
> >
> > 6 лет...
>
> Да, за 6 лет никто не сподобился даже попытаться прислать патч.
> Что как бы позволяет предложить, что - не жмёт.
или никто не может разобраться.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
Hello!
On Wed, Apr 22, 2020 at 06:15:07PM +0300, Slawa Olhovchenkov wrote:
> On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> >
> > > А это нормально что переменные $1..$N не являются локальными для
> > > регэкспа?
> > >
> > > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > > результате используется еще и результат map с регэкспом, то $1 будет
> > > браться из map.
> > > Что-то мне кажется это не логично.
> >
> > Это следствие того, что regexp и использование $1..$N могут быть
> > разнесены, например, в конструкциях вида (цитата из
> > http://nginx.org/r/if):
> >
> > if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> > set $id $1;
> > }
> >
> > Для rewrite'а это, конечно, не нормально, надо править. Про это
> > даже есть тикет:
>
> не для rewrite, а для map.
> вроде как логично ожидать, что map срабатывает выдавая указанную
> переменную без каких-либо дополнительных побочных эффектов.
Ну да, одно из возможных решений - отучить регулярные выражения в
map'е трогать $1..$N. С другой стороны - конфигурации вида
map $uri $foo {
~(.+) $1;
}
тоже никто не отменял.
> > https://trac.nginx.org/nginx/ticket/564
> >
> > Patches are welcome.
>
> 6 лет...
Да, за 6 лет никто не сподобился даже попытаться прислать патч.
Что как бы позволяет предложить, что - не жмёт.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
On Wed, Apr 22, 2020 at 05:39:23PM +0300, Maxim Dounin wrote:
> Hello!
>
> On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
>
> > А это нормально что переменные $1..$N не являются локальными для
> > регэкспа?
> >
> > Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> > результате используется еще и результат map с регэкспом, то $1 будет
> > браться из map.
> > Что-то мне кажется это не логично.
>
> Это следствие того, что regexp и использование $1..$N могут быть
> разнесены, например, в конструкциях вида (цитата из
> http://nginx.org/r/if):
>
> if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
> set $id $1;
> }
>
> Для rewrite'а это, конечно, не нормально, надо править. Про это
> даже есть тикет:
не для rewrite, а для map.
вроде как логично ожидать, что map срабатывает выдавая указанную
переменную без каких-либо дополнительных побочных эффектов.
> https://trac.nginx.org/nginx/ticket/564
>
> Patches are welcome.
6 лет...
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: переменные $1
Hello!
On Wed, Apr 22, 2020 at 04:31:02PM +0300, Slawa Olhovchenkov wrote:
> А это нормально что переменные $1..$N не являются локальными для
> регэкспа?
>
> Т.е. если например у нас есть rewrite и там что-то захватывается, а в
> результате используется еще и результат map с регэкспом, то $1 будет
> браться из map.
> Что-то мне кажется это не логично.
Это следствие того, что regexp и использование $1..$N могут быть
разнесены, например, в конструкциях вида (цитата из
http://nginx.org/r/if):
if ($http_cookie ~* "id=([^;]+)(?:;|$)") {
set $id $1;
}
Для rewrite'а это, конечно, не нормально, надо править. Про это
даже есть тикет:
https://trac.nginx.org/nginx/ticket/564
Patches are welcome.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
переменные $1
А это нормально что переменные $1..$N не являются локальными для регэкспа? Т.е. если например у нас есть rewrite и там что-то захватывается, а в результате используется еще и результат map с регэкспом, то $1 будет браться из map. Что-то мне кажется это не логично. ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Выбор upstream server в зависимости от типа clipher
On Wed, Apr 22, 2020 at 12:55:02PM +0500, Илья Шипицин wrote: >ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov <[1]b...@protva.ru>: > > On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote: > > но вы понимаете, что речь идет о stream-проксировании, т.е. вы > просто tcp > > поток отправляете на тот или иной бекенд и терминация SSL будет уже > на > > бекенде? > > Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello > и обработать ciphersuites ему нужно терминировать SSL. > >есть технология, в haproxy называется SNI based routing, когда из >SSL-хендшейков извлекается SNI (если он нешифрованный), и далее стрим без >терминации роутится. >в nginx это делается на ngx_stream_ssl_preread Да, не заметил, нужный модуль есть. Только функционала для выбора шифра не хватает. Значит, этот модуль и нужно слегка попатчить. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Выбор upstream server в зависимости от типа clipher
ср, 22 апр. 2020 г. в 12:51, Evgeniy Berdnikov : > On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote: > >но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто > tcp > >поток отправляете на тот или иной бекенд и терминация SSL будет уже на > >бекенде? > > Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello > и обработать ciphersuites ему нужно терминировать SSL. > есть технология, в haproxy называется SNI based routing, когда из SSL-хендшейков извлекается SNI (если он нешифрованный), и далее стрим без терминации роутится. в nginx это делается на ngx_stream_ssl_preread в SSL только пейлод шифрованный. сигнализация вся открытая и доступна без терминации > -- > Eugene Berdnikov > ___ > 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: Выбор upstream server в зависимости от типа clipher
On Wed, Apr 22, 2020 at 12:39:33PM +0500, Илья Шипицин wrote: >но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp >поток отправляете на тот или иной бекенд и терминация SSL будет уже на >бекенде? Nginx это не софтовый L4-роутер: чтобы разобрать ClientHello и обработать ciphersuites ему нужно терминировать SSL. -- Eugene Berdnikov ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Выбор upstream server в зависимости от типа clipher
да, на этом можно попробовать собрать map. но вы понимаете, что речь идет о stream-проксировании, т.е. вы просто tcp поток отправляете на тот или иной бекенд и терминация SSL будет уже на бекенде? ср, 22 апр. 2020 г. в 12:19, nerkas : > Илья. > Да, верно. Например, браузер Chromium GOST отправляет аж 22 шифра на выбор > (https://imgur.com/a/YdFmCld).Из них 4 это ГОСТ. > Я думал о варианте, что если какой-нибудь из GOST_ есть, то сразу > отправлять > на ГОСТ_ вебсервер, а там где ГОСТ-а нет, слать на другой. > > Posted at Nginx Forum: > https://forum.nginx.org/read.php?21,287748,287755#msg-287755 > > ___ > 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: Выбор upstream server в зависимости от типа clipher
Илья. Да, верно. Например, браузер Chromium GOST отправляет аж 22 шифра на выбор (https://imgur.com/a/YdFmCld).Из них 4 это ГОСТ. Я думал о варианте, что если какой-нибудь из GOST_ есть, то сразу отправлять на ГОСТ_ вебсервер, а там где ГОСТ-а нет, слать на другой. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,287748,287755#msg-287755 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
