Re: Route by request method
Понятно, спасибо!
вт, 9 февр. 2021 г. в 17:12, Maxim Dounin :
>
> Hello!
>
> On Tue, Feb 09, 2021 at 04:40:02PM +0300, Eugene Prokopiev wrote:
>
> > Но я вот задумался: а нельзя ли прямо внутри if использовать
> > pass_proxy? Тут -
> > https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
> > указан
> > сontext: if in location - значит можно? Я попробовал - не работает. Почему?
>
> Теоретически - можно. На практике - это чревато проблемами.
> Подробный ответ на вопрос "почему" есть в статье "if is evil", она
> ещё сохранилась в остатках wiki:
>
> https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
>
> Скажем, вот такая конфигурация работает без проблем:
>
> location / {
> if ($request_method != GET) {
> proxy_pass http://127.0.0.1:8081;
> }
>
> # static
> }
>
> Но уже вот такая сделает совсем не то, что хотелось бы:
>
> location / {
> if ($request_method != GET) {
> proxy_pass http://127.0.0.1:8081;
> }
>
> set $true 1;
> if ($true) {
> # nothing
> }
>
> # static
> }
>
> Конкретно для исходной задачи наиболее простым и органичным
> решением будет, IMHO, использование limit_except, как-то так:
>
> location / {
> limit_except GET {
> proxy_pass http://127.0.0.1:8081;
> }
>
> # static
> }
>
> Но и тут есть свои нюансы: скажем, если в location'е есть
> директивы модуля rewrite, в часности - те же if'ы, то они просто
> не будут работать для запросов, попавших в блок limit_except.
>
> Ну а наиболее универсальное решение из всех возможных уже привёл
> Олег - сделать rewrite по нужному условию в другой location и там
> уже делать что угодно.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Hello!
On Tue, Feb 09, 2021 at 04:40:02PM +0300, Eugene Prokopiev wrote:
> Но я вот задумался: а нельзя ли прямо внутри if использовать
> pass_proxy? Тут -
> https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
> указан
> сontext: if in location - значит можно? Я попробовал - не работает. Почему?
Теоретически - можно. На практике - это чревато проблемами.
Подробный ответ на вопрос "почему" есть в статье "if is evil", она
ещё сохранилась в остатках wiki:
https://www.nginx.com/resources/wiki/start/topics/depth/ifisevil/
Скажем, вот такая конфигурация работает без проблем:
location / {
if ($request_method != GET) {
proxy_pass http://127.0.0.1:8081;
}
# static
}
Но уже вот такая сделает совсем не то, что хотелось бы:
location / {
if ($request_method != GET) {
proxy_pass http://127.0.0.1:8081;
}
set $true 1;
if ($true) {
# nothing
}
# static
}
Конкретно для исходной задачи наиболее простым и органичным
решением будет, IMHO, использование limit_except, как-то так:
location / {
limit_except GET {
proxy_pass http://127.0.0.1:8081;
}
# static
}
Но и тут есть свои нюансы: скажем, если в location'е есть
директивы модуля rewrite, в часности - те же if'ы, то они просто
не будут работать для запросов, попавших в блок limit_except.
Ну а наиболее универсальное решение из всех возможных уже привёл
Олег - сделать rewrite по нужному условию в другой location и там
уже делать что угодно.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Спасибо!
Но я вот задумался: а нельзя ли прямо внутри if использовать
pass_proxy? Тут -
https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_pass
указан
сontext: if in location - значит можно? Я попробовал - не работает. Почему?
вт, 9 февр. 2021 г. в 15:52, Oleg A. Mamontov :
>
> On Tue, Feb 09, 2021 at 03:36:49PM +0300, Eugene Prokopiev wrote:
> >Всем спасибо!
> >
> >А нет ли чего-то среднего: передать запрос с помощью rewrite (это
> >выглядит чище использования фиктивного статуса, хотя явный goto был бы
> >еще чище) в именованный @location вместо internal (тогда переменная
> >request_filename будет содержать правильное значение)?
>
> Если вам хочется возвращать $uri в исходное значение, то это также
> достигается посредством rewrite, заодно тогда и trailing slash не нужен:
> ---
> location / {
> if ($request_method != 'GET') {
> rewrite ^/(.*) /proxy/$1 last;
> }
> root /data;
> }
> location /proxy/ {
> internal;
> rewrite ^/proxy/(.*) /$1 break;
> proxy_pass http://127.0.0.1:8080;
> }
> ---
>
> >вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
> >>
> >> можно на limit_except разрешить только GET. остальное попадет в запрет и
> >> навешать на него кастомную страницу ошибки
> >>
> >> вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
> >>>
> >>> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
> >>> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
> >>> >
> >>> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
> >>> >>обработку запроса в другой location. Обратите внимание - trailing slash
> >>> >>в proxy_pass в данном случае имеет значение.
> >>> >>---
> >>> >>location / {
> >>> >> if ($request_method != 'GET') {
> >>> >> rewrite ^/(.*) /proxy/$1 last;
> >>> >> }
> >>> >> root /data;
> >>> >>}
> >>> >>location /proxy/ {
> >>> >> internal;
> >>> >> proxy_pass http://127.0.0.1:8080/;
> >>> >>}
> >>> >
> >>> >Возможно переход в именованный location с помощью директив
> >>> >"error_page 418 = @location; return 418;" будет лучше
> >>> >с точки зрения читабельности, чем rewrite директивы,
> >>> >делающие конфиг nginx похожим на конфиг sendmail?
> >>>
> >>> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
> >>> с error_page лучше для решения поставленной задачи.
> >>>
> >>> Что вижу: нецелевое использование директивы / фиктивного статуса,
> >>> появление лишней строки в конфиге и необходимость включать
> >>> recursive_error_pages при использовании реальной обработки последующих
> >>> ошибок проксирования.
> >>>
> >>> Но согласен - так делать тоже можно, TMTOWTDI
> >>>
> >>> >location / {
> >>> >if ($request_method != 'GET') {
> >>> >error_page 418 = @proxy;
> >>> >return 418;
> >>> >}
> >>> >root /data;
> >>> >}
> >>> >location @proxy {
> >>> >proxy_pass http://127.0.0.1:8080;
> >>> >}
> >>> >
> >>> >По-сути вот этот набор из двух директив:
> >>> >"error_page 418 = @location; return 418;"
> >>> >означает простое действие "goto @location;"
> >>> >
> >>> >--
> >>> >Best regards,
> >>> > Gena
> >>> >
> >>> >___
> >>> >nginx-ru mailing list
> >>> >nginx-ru@nginx.org
> >>> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>>
> >>> --
> >>> Cheers,
> >>> Oleg A. Mamontov
> >>>
> >>> mailto: o...@mamontov.net
> >>>
> >>> skype: lonerr11
> >>> cell: +7 (903) 798-1352
> >>> ___
> >>> 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
> >
> >
> >
> >--
> >WBR,
> >Eugene Prokopiev
> >___
> >nginx-ru mailing list
> >nginx-ru@nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Cheers,
> Oleg A. Mamontov
>
> mailto: o...@mamontov.net
>
> skype: lonerr11
> cell: +7 (903) 798-1352
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
On Tue, Feb 09, 2021 at 03:36:49PM +0300, Eugene Prokopiev wrote:
Всем спасибо!
А нет ли чего-то среднего: передать запрос с помощью rewrite (это
выглядит чище использования фиктивного статуса, хотя явный goto был бы
еще чище) в именованный @location вместо internal (тогда переменная
request_filename будет содержать правильное значение)?
Если вам хочется возвращать $uri в исходное значение, то это также
достигается посредством rewrite, заодно тогда и trailing slash не нужен:
---
location / {
if ($request_method != 'GET') {
rewrite ^/(.*) /proxy/$1 last;
}
root /data;
}
location /proxy/ {
internal;
rewrite ^/proxy/(.*) /$1 break;
proxy_pass http://127.0.0.1:8080;
}
---
вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
можно на limit_except разрешить только GET. остальное попадет в запрет и
навешать на него кастомную страницу ошибки
вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
>On 08.02.2021 23:24, Oleg A. Mamontov wrote:
>
>>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
>>обработку запроса в другой location. Обратите внимание - trailing slash
>>в proxy_pass в данном случае имеет значение.
>>---
>>location / {
>> if ($request_method != 'GET') {
>> rewrite ^/(.*) /proxy/$1 last;
>> }
>> root /data;
>>}
>>location /proxy/ {
>> internal;
>> proxy_pass http://127.0.0.1:8080/;
>>}
>
>Возможно переход в именованный location с помощью директив
>"error_page 418 = @location; return 418;" будет лучше
>с точки зрения читабельности, чем rewrite директивы,
>делающие конфиг nginx похожим на конфиг sendmail?
Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
с error_page лучше для решения поставленной задачи.
Что вижу: нецелевое использование директивы / фиктивного статуса,
появление лишней строки в конфиге и необходимость включать
recursive_error_pages при использовании реальной обработки последующих
ошибок проксирования.
Но согласен - так делать тоже можно, TMTOWTDI
>location / {
>if ($request_method != 'GET') {
>error_page 418 = @proxy;
>return 418;
>}
>root /data;
>}
>location @proxy {
>proxy_pass http://127.0.0.1:8080;
>}
>
>По-сути вот этот набор из двух директив:
>"error_page 418 = @location; return 418;"
>означает простое действие "goto @location;"
>
>--
>Best regards,
> Gena
>
>___
>nginx-ru mailing list
>nginx-ru@nginx.org
>http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Cheers,
Oleg A. Mamontov
mailto: o...@mamontov.net
skype: lonerr11
cell: +7 (903) 798-1352
___
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
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Cheers,
Oleg A. Mamontov
mailto: o...@mamontov.net
skype: lonerr11
cell: +7 (903) 798-1352
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Оказывается, это известный (и неудовлетворенный) фичреквест -
http://mailman.nginx.org/pipermail/nginx-ru/2011-October/043596.html
вт, 9 февр. 2021 г. в 15:36, Eugene Prokopiev :
>
> Всем спасибо!
>
> А нет ли чего-то среднего: передать запрос с помощью rewrite (это
> выглядит чище использования фиктивного статуса, хотя явный goto был бы
> еще чище) в именованный @location вместо internal (тогда переменная
> request_filename будет содержать правильное значение)?
>
> вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
> >
> > можно на limit_except разрешить только GET. остальное попадет в запрет и
> > навешать на него кастомную страницу ошибки
> >
> > вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
> >>
> >> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
> >> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
> >> >
> >> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
> >> >>обработку запроса в другой location. Обратите внимание - trailing slash
> >> >>в proxy_pass в данном случае имеет значение.
> >> >>---
> >> >>location / {
> >> >> if ($request_method != 'GET') {
> >> >> rewrite ^/(.*) /proxy/$1 last;
> >> >> }
> >> >> root /data;
> >> >>}
> >> >>location /proxy/ {
> >> >> internal;
> >> >> proxy_pass http://127.0.0.1:8080/;
> >> >>}
> >> >
> >> >Возможно переход в именованный location с помощью директив
> >> >"error_page 418 = @location; return 418;" будет лучше
> >> >с точки зрения читабельности, чем rewrite директивы,
> >> >делающие конфиг nginx похожим на конфиг sendmail?
> >>
> >> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
> >> с error_page лучше для решения поставленной задачи.
> >>
> >> Что вижу: нецелевое использование директивы / фиктивного статуса,
> >> появление лишней строки в конфиге и необходимость включать
> >> recursive_error_pages при использовании реальной обработки последующих
> >> ошибок проксирования.
> >>
> >> Но согласен - так делать тоже можно, TMTOWTDI
> >>
> >> >location / {
> >> >if ($request_method != 'GET') {
> >> >error_page 418 = @proxy;
> >> >return 418;
> >> >}
> >> >root /data;
> >> >}
> >> >location @proxy {
> >> >proxy_pass http://127.0.0.1:8080;
> >> >}
> >> >
> >> >По-сути вот этот набор из двух директив:
> >> >"error_page 418 = @location; return 418;"
> >> >означает простое действие "goto @location;"
> >> >
> >> >--
> >> >Best regards,
> >> > Gena
> >> >
> >> >___
> >> >nginx-ru mailing list
> >> >nginx-ru@nginx.org
> >> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
> >>
> >> --
> >> Cheers,
> >> Oleg A. Mamontov
> >>
> >> mailto: o...@mamontov.net
> >>
> >> skype: lonerr11
> >> cell: +7 (903) 798-1352
> >> ___
> >> 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
>
>
>
> --
> WBR,
> Eugene Prokopiev
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Всем спасибо!
А нет ли чего-то среднего: передать запрос с помощью rewrite (это
выглядит чище использования фиктивного статуса, хотя явный goto был бы
еще чище) в именованный @location вместо internal (тогда переменная
request_filename будет содержать правильное значение)?
вт, 9 февр. 2021 г. в 11:20, Илья Шипицин :
>
> можно на limit_except разрешить только GET. остальное попадет в запрет и
> навешать на него кастомную страницу ошибки
>
> вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
>>
>> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
>> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
>> >
>> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
>> >>обработку запроса в другой location. Обратите внимание - trailing slash
>> >>в proxy_pass в данном случае имеет значение.
>> >>---
>> >>location / {
>> >> if ($request_method != 'GET') {
>> >> rewrite ^/(.*) /proxy/$1 last;
>> >> }
>> >> root /data;
>> >>}
>> >>location /proxy/ {
>> >> internal;
>> >> proxy_pass http://127.0.0.1:8080/;
>> >>}
>> >
>> >Возможно переход в именованный location с помощью директив
>> >"error_page 418 = @location; return 418;" будет лучше
>> >с точки зрения читабельности, чем rewrite директивы,
>> >делающие конфиг nginx похожим на конфиг sendmail?
>>
>> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
>> с error_page лучше для решения поставленной задачи.
>>
>> Что вижу: нецелевое использование директивы / фиктивного статуса,
>> появление лишней строки в конфиге и необходимость включать
>> recursive_error_pages при использовании реальной обработки последующих
>> ошибок проксирования.
>>
>> Но согласен - так делать тоже можно, TMTOWTDI
>>
>> >location / {
>> >if ($request_method != 'GET') {
>> >error_page 418 = @proxy;
>> >return 418;
>> >}
>> >root /data;
>> >}
>> >location @proxy {
>> >proxy_pass http://127.0.0.1:8080;
>> >}
>> >
>> >По-сути вот этот набор из двух директив:
>> >"error_page 418 = @location; return 418;"
>> >означает простое действие "goto @location;"
>> >
>> >--
>> >Best regards,
>> > Gena
>> >
>> >___
>> >nginx-ru mailing list
>> >nginx-ru@nginx.org
>> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>> --
>> Cheers,
>> Oleg A. Mamontov
>>
>> mailto: o...@mamontov.net
>>
>> skype: lonerr11
>> cell: +7 (903) 798-1352
>> ___
>> 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
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
можно на limit_except разрешить только GET. остальное попадет в запрет и
навешать на него кастомную страницу ошибки
вт, 9 февр. 2021 г. в 13:17, Oleg A. Mamontov :
> On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
> >On 08.02.2021 23:24, Oleg A. Mamontov wrote:
> >
> >>"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
> >>обработку запроса в другой location. Обратите внимание - trailing slash
> >>в proxy_pass в данном случае имеет значение.
> >>---
> >>location / {
> >> if ($request_method != 'GET') {
> >> rewrite ^/(.*) /proxy/$1 last;
> >> }
> >> root /data;
> >>}
> >>location /proxy/ {
> >> internal;
> >> proxy_pass http://127.0.0.1:8080/;
> >>}
> >
> >Возможно переход в именованный location с помощью директив
> >"error_page 418 = @location; return 418;" будет лучше
> >с точки зрения читабельности, чем rewrite директивы,
> >делающие конфиг nginx похожим на конфиг sendmail?
>
> Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
> с error_page лучше для решения поставленной задачи.
>
> Что вижу: нецелевое использование директивы / фиктивного статуса,
> появление лишней строки в конфиге и необходимость включать
> recursive_error_pages при использовании реальной обработки последующих
> ошибок проксирования.
>
> Но согласен - так делать тоже можно, TMTOWTDI
>
> >location / {
> >if ($request_method != 'GET') {
> >error_page 418 = @proxy;
> >return 418;
> >}
> >root /data;
> >}
> >location @proxy {
> >proxy_pass http://127.0.0.1:8080;
> >}
> >
> >По-сути вот этот набор из двух директив:
> >"error_page 418 = @location; return 418;"
> >означает простое действие "goto @location;"
> >
> >--
> >Best regards,
> > Gena
> >
> >___
> >nginx-ru mailing list
> >nginx-ru@nginx.org
> >http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> --
> Cheers,
> Oleg A. Mamontov
>
> mailto: o...@mamontov.net
>
> skype: lonerr11
> cell: +7 (903) 798-1352
> ___
> 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: Route by request method
On Tue, Feb 09, 2021 at 12:48:55AM +0200, Gena Makhomed wrote:
On 08.02.2021 23:24, Oleg A. Mamontov wrote:
"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
обработку запроса в другой location. Обратите внимание - trailing slash
в proxy_pass в данном случае имеет значение.
---
location / {
if ($request_method != 'GET') {
rewrite ^/(.*) /proxy/$1 last;
}
root /data;
}
location /proxy/ {
internal;
proxy_pass http://127.0.0.1:8080/;
}
Возможно переход в именованный location с помощью директив
"error_page 418 = @location; return 418;" будет лучше
с точки зрения читабельности, чем rewrite директивы,
делающие конфиг nginx похожим на конфиг sendmail?
Я не вижу аналогии с sendmail.cf равно как и не вижу, чем подход
с error_page лучше для решения поставленной задачи.
Что вижу: нецелевое использование директивы / фиктивного статуса,
появление лишней строки в конфиге и необходимость включать
recursive_error_pages при использовании реальной обработки последующих
ошибок проксирования.
Но согласен - так делать тоже можно, TMTOWTDI
location / {
if ($request_method != 'GET') {
error_page 418 = @proxy;
return 418;
}
root /data;
}
location @proxy {
proxy_pass http://127.0.0.1:8080;
}
По-сути вот этот набор из двух директив:
"error_page 418 = @location; return 418;"
означает простое действие "goto @location;"
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Cheers,
Oleg A. Mamontov
mailto: o...@mamontov.net
skype: lonerr11
cell: +7 (903) 798-1352
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
On 08.02.2021 23:24, Oleg A. Mamontov wrote:
"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
обработку запроса в другой location. Обратите внимание - trailing slash
в proxy_pass в данном случае имеет значение.
---
location / {
if ($request_method != 'GET') {
rewrite ^/(.*) /proxy/$1 last;
}
root /data;
}
location /proxy/ {
internal;
proxy_pass http://127.0.0.1:8080/;
}
Возможно переход в именованный location с помощью директив
"error_page 418 = @location; return 418;" будет лучше
с точки зрения читабельности, чем rewrite директивы,
делающие конфиг nginx похожим на конфиг sendmail?
location / {
if ($request_method != 'GET') {
error_page 418 = @proxy;
return 418;
}
root /data;
}
location @proxy {
proxy_pass http://127.0.0.1:8080;
}
По-сути вот этот набор из двух директив:
"error_page 418 = @location; return 418;"
означает простое действие "goto @location;"
--
Best regards,
Gena
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
On Mon, Feb 08, 2021 at 07:15:43PM +0300, Eugene Prokopiev wrote:
Здравствуйте!
Требуется по GET /data.txt отдавать самый файл как есть, а по
POST/PUT/DELETE /data.txt передавать запрос в какой-то бакенд через
proxy_pass - по идее не самый редкий кейс, но никакого пример
нагуглить не могу. Попробовал сделать так:
location / {
if ($request_method = 'GET') {
root /data;
}
proxy_pass http://127.0.0.1:8080;
}
Но в if ничего не попадает. Я что-то делаю не неправильно? Или это
вообще принято делать иначе?
"Традиционный" подход - сделать по требуемому условию rewrite, уводящий
обработку запроса в другой location. Обратите внимание - trailing slash
в proxy_pass в данном случае имеет значение.
---
location / {
if ($request_method != 'GET') {
rewrite ^/(.*) /proxy/$1 last;
}
root /data;
}
location /proxy/ {
internal;
proxy_pass http://127.0.0.1:8080/;
}
---
--
WBR,
Eugene Prokopiev
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
--
Cheers,
Oleg A. Mamontov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Route by request method
Судя по гуглу, можно попробовать так:
location / {
if ($request_method = GET) {
root /data;
}
if ($request_method != GET) {
proxy_pass http://127.0.0.1:8080;
}
}
08.02.2021 23:15, Eugene Prokopiev пишет:
Здравствуйте!
Требуется по GET /data.txt отдавать самый файл как есть, а по
POST/PUT/DELETE /data.txt передавать запрос в какой-то бакенд через
proxy_pass - по идее не самый редкий кейс, но никакого пример
нагуглить не могу. Попробовал сделать так:
location / {
if ($request_method = 'GET') {
root /data;
}
proxy_pass http://127.0.0.1:8080;
}
Но в if ничего не попадает. Я что-то делаю не неправильно? Или это
вообще принято делать иначе?
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
