Hello!

On Wed, Jan 27, 2021 at 07:14:27PM +0300, Slawa Olhovchenkov wrote:

> On Wed, Jan 27, 2021 at 07:07:35PM +0300, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Wed, Jan 27, 2021 at 06:43:10PM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Wed, Jan 27, 2021 at 06:34:15PM +0300, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Wed, Jan 27, 2021 at 05:08:45PM +0300, Slawa Olhovchenkov wrote:
> > > >
> > > > > А возможна ли конструкция типа такой:
> > > > >
> > > > > location / {
> > > > > rewrite ....;
> > > > > rewrite ....;
> > > > > location ~ /../(..)... {
> > > > > try_files /$2/$3/$2$3$4_$1.bin @proxy;
> > > > > }
> > > > > location / {
> > > > > try_files /notexist @proxy;
> > > > > }
> > > > > }
> > > > > location @proxy {
> > > > > }
> > > > >
> > > > > Ну т.е. смысл в том, что не попадает под маску -- сразу брать с
> > > > > апстрима, а что под маску попадает -- проверять на диске и если нет --
> > > > > брать с апстрима.
> > > >
> > > > Возможна. Впрочем, в предложенной конструкции вложенный "location /"
> > > > избыточен, его содержимое можно написать непосредственно во
> > > > внешнем "location /".
> > >
> > > а кстати, есть ли какой-то более изящный способ сделать внутрений
> > > редирект на @proxy в данном случае?
> >
> > Можно сделать
> >
> > error_page 418 @proxy;
> > return 418;
> >
> > "Более изящный" ли это способ - затрудняюсь сказать, но более
> > смешной.
> >
> > Более правильным в данном случае будет просто прописать
> > проксирование явно.
>
> в смысле два раза копировать конфигурацию прокси?
> она сильно развесистая, не хотелось бы дублирования.

Конфигурацию прокси можно задать на уровне http или server, а в
соответствующих location'ах писать исключительно proxy_pass. Если
конфигурацию зачем-то требуется задавать непосредственно в
location - то это можно сделать с помощью директивы include.

> > > > Заодно и написанные во внешнем "location /" директивы rewrite
> > > > обретут какой-то смысл (впрочем, скорее всего по прежнему
> > > > неверный, так как эти директивы не применяются к запросам,
> > > > попавшим в любой из вложенных location'ов).
> > >
> > > разве rewrite применяется не до разбора вложенных локейшинов?
> >
> > Нет. Дерево location'ов - общее, поиск подходящего location'а по
> > URI - это единая операция. Директивы rewrite применяются из
> > найденного подходящего к запросу location'а. Подробности
> > применения директив rewrite расписаны в описании модуля rewrite,
> > тут:
> >
> > http://nginx.org/ru/docs/http/ngx_http_rewrite_module.html
>
> читал, но понял видимо неправильно, в том куске который "Если
> директива указана внутри location, дальнейшая обработка запроса
> продолжается в этом location.". я это понял так, что при наличии там
> вложенных локейшинов подбор будет продолжен с них.

Это часть описания директивы break, и она верна в том смысле, что
если директива break будет выполнена - то дальнейшкая обработка
продолжится в том location, в котором указана директива break, то
есть даже если URI запроса изменился, nginx не будет снова искать
location, соответствующий новому URI запроса.

Читать в первую очередь следует основную схему работы, которая
расписана непосредственно в описании модуля:

: Директивы break, if, return, rewrite и set обрабатываются в
: следующем порядке:
:
: - последовательно выполняются директивы этого модуля, описанные на
: уровне server;
: - в цикле:
: - ищется location по URI запроса;
: - последовательно выполняются директивы этого модуля, описанные в
: найденном location;
: - цикл повторяется, если URI запроса изменялся, но не более 10 раз.

Соответственно директива break позволяет изменить URI и выйти из
цикла несмотря на это, но никак не влияет на то, что поиск
location по URI запроса - единая операция.

> а почему, кстати, может игнориоваться директива set?
> я по дебаг логу смотрю, попадаю во вложенный локейшен, там у меня есть
> set но он даже выполняться не собирался.

Простейшая причина - обработка директив модуля rewrite остановлена
с помощью директивы break или "rewrite ... break".

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