Re: Почему пустой if ломает работу try files?
читаемость штука субъективная и скорее предмет холиваров. уверен, найдется
непустое множество людей, для которых ваш вариант нечитаемый.
наверное, хороший ответ про недостаток читаемости может заключаться в том,
что конфиг можно сопровождать комментариями, улучшающими читаемость.
а добавить кусок кода, который будет делать примерно то, что можно сделать
без него, это усложнение на ровном месте и потенциальный источник ошибок
ср, 30 сент. 2020 г. в 10:44, Alexey Galygin :
> да, примеры были из habr, но и там к статье были претензии к map-решению
> + я специально усложнил пример регулярными выражениями
>
> поэтому указанный map это не эквивалент
>
> во вторых плохо читаемый хак и издевательство над линейной логикой
> зачем такие костыли, если можно доделать нормальный if?
>
>
>
> On 30 Sep 2020, at 05:14, fox wrote:
>
> Троллишь?
>
> map "$http_user_agent:$method:$uri" $block {
>"HackYou:POST:/admin/some/url" "1";
> }
>
> if ($block) {
>return 403;
> }
>
>
> 30.09.2020 02:24, Alexey Galygin пишет:
>
> не вкусовщина
> часто очень не хватает простейших and/&& и or/||
>
> вот чтобы такое не писать:
>
> if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") {
> set$block"${block}B"; } if($uri~ “^/admin/some/url") {
> set$block"${block}C"; } if($block= "ABC") { return403; }
>
> vs условно:
>
> if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~
> “^/admin/some/url”) {
> return403;
> }
>
>
> On 29 Sep 2020, at 21:49, Илья Шипицин > wrote:
>
> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в
> определенном синтаксисе.
> сейчас вы точно так же выражаете свою мысль через map-ы.
>
> по сути просто диалекты языка
>
> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin >:
>
>иногда трудно обойтись без дополнительной логики,
>которую ради такой мелочи отдавать на backend грустно
>
>и речь про улучшение поведения исключительно с обратной совместимостью
>
>если совсем никак, то можно добавить условно extended if — eif
>
>
> On 29 Sep 2020, at 19:47, fox
>> wrote:
>
>
> 1) может, потому что конфиг - это не язык программирования?
>
> 2) изменение поведения сломает тысячи существующих систем.
>
>
> 29.09.2020 23:31, Alexey Galygin пишет:
>
> присоединяюсь к вопросу:
>
> почему бы не сделать if нормальным? чтобы без артефактов… и
>
>немного мощнее
>
>
> нам вот тоже приходится делать по несколько map, чтобы логику
>
>чуть более сложную построить…
>
> и это ужас
>
> On 29 Sep 2020, at 19:29, Sergey Kandaurov
>> wrote:
>
>
>
> On 29 Sep 2020, at 17:12, Ilya Evseev
>
>mailto:nginx-fo...@forum.nginx.org
> >>
>wrote:
>
>
> Имеется nginx 1.19.2 со следующей настройкой:
>
> server {
> location / {
> if ($http_user_agent ~ "TestAgent") { }
> try_files $uri $uri/ /index.html;
> }
> }
>
> Почему попадание в if меняет логику работы последующего
>
>try_files?
>
>
> https://wiki.nginx.org/IfIsEvil
>
> --
> Sergey Kandaurov
>
> ___
> 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
>
>
> ___
> 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
>
> ___
> 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
>
>
> ___
> 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему пустой if ломает работу try files?
Троллишь?
map "$http_user_agent:$method:$uri" $block {
"HackYou:POST:/admin/some/url" "1";
}
if ($block) {
return 403;
}
30.09.2020 02:24, Alexey Galygin пишет:
> не вкусовщина
> часто очень не хватает простейших and/&& и or/||
>
> вот чтобы такое не писать:
>
> if($http_user_agent~ "HackYou"){ set$block"A"; } if($method= "POST") {
> set$block"${block}B"; } if($uri~ “^/admin/some/url") {
> set$block"${block}C"; } if($block= "ABC") { return403; }
>
> vs условно:
>
> if/eif ($http_user_agent~ “HackYou” && $method= “POST” && $uri~
> “^/admin/some/url”) {
> return403;
> }
>
>
>> On 29 Sep 2020, at 21:49, Илья Шипицин > > wrote:
>>
>> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в
>> определенном синтаксисе.
>> сейчас вы точно так же выражаете свою мысль через map-ы.
>>
>> по сути просто диалекты языка
>>
>> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin > >:
>>
>> иногда трудно обойтись без дополнительной логики,
>> которую ради такой мелочи отдавать на backend грустно
>>
>> и речь про улучшение поведения исключительно с обратной совместимостью
>>
>> если совсем никак, то можно добавить условно extended if — eif
>>
>>
>> > On 29 Sep 2020, at 19:47, fox > > wrote:
>> >
>> > 1) может, потому что конфиг - это не язык программирования?
>> >
>> > 2) изменение поведения сломает тысячи существующих систем.
>> >
>> >
>> > 29.09.2020 23:31, Alexey Galygin пишет:
>> >> присоединяюсь к вопросу:
>> >>
>> >> почему бы не сделать if нормальным? чтобы без артефактов… и
>> немного мощнее
>> >>
>> >> нам вот тоже приходится делать по несколько map, чтобы логику
>> чуть более сложную построить…
>> >> и это ужас
>> >>
>> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov > > wrote:
>> >>>
>> >>>
>> On 29 Sep 2020, at 17:12, Ilya Evseev
>> mailto:nginx-fo...@forum.nginx.org>>
>> wrote:
>>
>> Имеется nginx 1.19.2 со следующей настройкой:
>>
>> server {
>> location / {
>> if ($http_user_agent ~ "TestAgent") { }
>> try_files $uri $uri/ /index.html;
>> }
>> }
>>
>> Почему попадание в if меняет логику работы последующего
>> try_files?
>> >>>
>> >>> https://wiki.nginx.org/IfIsEvil
>> >>>
>> >>> --
>> >>> Sergey Kandaurov
>> >>>
>> >>> ___
>> >>> 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
>> >>
>> >
>> > ___
>> > 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
>>
>> ___
>> 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему пустой if ломает работу try files?
не вкусовщина
часто очень не хватает простейших and/&& и or/||
вот чтобы такое не писать:
if ($http_user_agent ~ "HackYou") {
set $block "A";
}
if ($method = "POST") {
set $block "${block}B";
}
if ($uri ~ “^/admin/some/url") {
set $block "${block}C";
}
if ($block = "ABC") {
return 403;
}
vs условно:
if/eif ($http_user_agent ~ “HackYou” && $method = “POST” && $uri ~
“^/admin/some/url”) {
return 403;
}
> On 29 Sep 2020, at 21:49, Илья Шипицин wrote:
>
> это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в
> определенном синтаксисе.
> сейчас вы точно так же выражаете свою мысль через map-ы.
>
> по сути просто диалекты языка
>
> вт, 29 сент. 2020 г. в 22:41, Alexey Galygin >:
> иногда трудно обойтись без дополнительной логики,
> которую ради такой мелочи отдавать на backend грустно
>
> и речь про улучшение поведения исключительно с обратной совместимостью
>
> если совсем никак, то можно добавить условно extended if — eif
>
>
> > On 29 Sep 2020, at 19:47, fox mailto:red-f...@ya.ru>>
> > wrote:
> >
> > 1) может, потому что конфиг - это не язык программирования?
> >
> > 2) изменение поведения сломает тысячи существующих систем.
> >
> >
> > 29.09.2020 23:31, Alexey Galygin пишет:
> >> присоединяюсь к вопросу:
> >>
> >> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее
> >>
> >> нам вот тоже приходится делать по несколько map, чтобы логику чуть более
> >> сложную построить…
> >> и это ужас
> >>
> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov >>> > wrote:
> >>>
> >>>
> On 29 Sep 2020, at 17:12, Ilya Evseev > wrote:
>
> Имеется nginx 1.19.2 со следующей настройкой:
>
> server {
> location / {
> if ($http_user_agent ~ "TestAgent") { }
> try_files $uri $uri/ /index.html;
> }
> }
>
> Почему попадание в if меняет логику работы последующего try_files?
> >>>
> >>> https://wiki.nginx.org/IfIsEvil
> >>>
> >>> --
> >>> Sergey Kandaurov
> >>>
> >>> ___
> >>> 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
> >>
> >>
> >
> > ___
> > 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
> ___
> 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: Почему пустой if ломает работу try files?
иногда трудно обойтись без дополнительной логики,
которую ради такой мелочи отдавать на backend грустно
и речь про улучшение поведения исключительно с обратной совместимостью
если совсем никак, то можно добавить условно extended if — eif
> On 29 Sep 2020, at 19:47, fox wrote:
>
> 1) может, потому что конфиг - это не язык программирования?
>
> 2) изменение поведения сломает тысячи существующих систем.
>
>
> 29.09.2020 23:31, Alexey Galygin пишет:
>> присоединяюсь к вопросу:
>>
>> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее
>>
>> нам вот тоже приходится делать по несколько map, чтобы логику чуть более
>> сложную построить…
>> и это ужас
>>
>>> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote:
>>>
>>>
On 29 Sep 2020, at 17:12, Ilya Evseev wrote:
Имеется nginx 1.19.2 со следующей настройкой:
server {
location / {
if ($http_user_agent ~ "TestAgent") { }
try_files $uri $uri/ /index.html;
}
}
Почему попадание в if меняет логику работы последующего try_files?
>>>
>>> https://wiki.nginx.org/IfIsEvil
>>>
>>> --
>>> Sergey Kandaurov
>>>
>>> ___
>>> 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
>>
>
> ___
> 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: Почему пустой if ломает работу try files?
присоединяюсь к вопросу:
почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее
нам вот тоже приходится делать по несколько map, чтобы логику чуть более
сложную построить…
и это ужас
> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote:
>
>
>> On 29 Sep 2020, at 17:12, Ilya Evseev wrote:
>>
>> Имеется nginx 1.19.2 со следующей настройкой:
>>
>> server {
>> location / {
>> if ($http_user_agent ~ "TestAgent") { }
>> try_files $uri $uri/ /index.html;
>> }
>> }
>>
>> Почему попадание в if меняет логику работы последующего try_files?
>
> https://wiki.nginx.org/IfIsEvil
>
> --
> Sergey Kandaurov
>
> ___
> 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: Почему пустой if ломает работу try files?
это вкусовщина же. вы готовы писать "eif", чтобы выразить свою мысль в
определенном синтаксисе.
сейчас вы точно так же выражаете свою мысль через map-ы.
по сути просто диалекты языка
вт, 29 сент. 2020 г. в 22:41, Alexey Galygin :
> иногда трудно обойтись без дополнительной логики,
> которую ради такой мелочи отдавать на backend грустно
>
> и речь про улучшение поведения исключительно с обратной совместимостью
>
> если совсем никак, то можно добавить условно extended if — eif
>
>
> > On 29 Sep 2020, at 19:47, fox wrote:
> >
> > 1) может, потому что конфиг - это не язык программирования?
> >
> > 2) изменение поведения сломает тысячи существующих систем.
> >
> >
> > 29.09.2020 23:31, Alexey Galygin пишет:
> >> присоединяюсь к вопросу:
> >>
> >> почему бы не сделать if нормальным? чтобы без артефактов… и немного
> мощнее
> >>
> >> нам вот тоже приходится делать по несколько map, чтобы логику чуть
> более сложную построить…
> >> и это ужас
> >>
> >>> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote:
> >>>
> >>>
> On 29 Sep 2020, at 17:12, Ilya Evseev
> wrote:
>
> Имеется nginx 1.19.2 со следующей настройкой:
>
> server {
> location / {
> if ($http_user_agent ~ "TestAgent") { }
> try_files $uri $uri/ /index.html;
> }
> }
>
> Почему попадание в if меняет логику работы последующего try_files?
> >>>
> >>> https://wiki.nginx.org/IfIsEvil
> >>>
> >>> --
> >>> Sergey Kandaurov
> >>>
> >>> ___
> >>> 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
> >>
> >
> > ___
> > 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
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему пустой if ломает работу try files?
1) может, потому что конфиг - это не язык программирования?
2) изменение поведения сломает тысячи существующих систем.
29.09.2020 23:31, Alexey Galygin пишет:
> присоединяюсь к вопросу:
>
> почему бы не сделать if нормальным? чтобы без артефактов… и немного мощнее
>
> нам вот тоже приходится делать по несколько map, чтобы логику чуть более
> сложную построить…
> и это ужас
>
>> On 29 Sep 2020, at 19:29, Sergey Kandaurov wrote:
>>
>>
>>> On 29 Sep 2020, at 17:12, Ilya Evseev wrote:
>>>
>>> Имеется nginx 1.19.2 со следующей настройкой:
>>>
>>> server {
>>> location / {
>>> if ($http_user_agent ~ "TestAgent") { }
>>> try_files $uri $uri/ /index.html;
>>> }
>>> }
>>>
>>> Почему попадание в if меняет логику работы последующего try_files?
>>
>> https://wiki.nginx.org/IfIsEvil
>>
>> --
>> Sergey Kandaurov
>>
>> ___
>> 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
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Почему пустой if ломает работу try files?
> On 29 Sep 2020, at 17:12, Ilya Evseev wrote:
>
> Имеется nginx 1.19.2 со следующей настройкой:
>
>server {
>location / {
>if ($http_user_agent ~ "TestAgent") { }
>try_files $uri $uri/ /index.html;
>}
>}
>
> Почему попадание в if меняет логику работы последующего try_files?
https://wiki.nginx.org/IfIsEvil
--
Sergey Kandaurov
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Почему пустой if ломает работу try files?
Имеется nginx 1.19.2 со следующей настройкой:
server {
location / {
if ($http_user_agent ~ "TestAgent") { }
try_files $uri $uri/ /index.html;
}
}
Проверяю:
1) curl http://127.0.0.1/unknown -- правильно возвращает index.html
2) curl http://127.0.0.1/ -H 'User-Agent: TestAgent' -- правильно возвращает
index.html
3) curl http://127.0.0.1/unknown -H 'User-Agent: TestAgent' -- неправильно
возвращает ошибку 404
Почему попадание в if меняет логику работы последующего try_files?
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,289591,289591#msg-289591
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
[nginx-ru-announce] nginx-1.19.3
Изменения в nginx 1.19.3 29.09.2020 *) Добавление: модуль ngx_stream_set_module. *) Добавление: директива proxy_cookie_flags. *) Добавление: директива userid_flags. *) Исправление: расширение управления кэшированием stale-if-error ошибочно применялось, если бэкенд возвращал ответ с кодом 500, 502, 503, 504, 403, 404 или 429. *) Исправление: если использовалось кэширование и бэкенд возвращал ответы с строкой заголовка Vary, в логах могли появляться сообщения "[crit] cache file ... has too long header". *) Изменение: при использовании OpenSSL 1.1.1 в логах могли появляться сообщения "[crit] SSL_write() failed". *) Исправление: в логах могли появляться сообщения "SSL_shutdown() failed (SSL: ... bad write retry)"; ошибка появилась в 1.19.2. *) Исправление: при использовании HTTP/2 в рабочем процессе мог произойти segmentation fault, если ошибки с кодом 400 с помощью директивы error_page перенаправлялись в проксируемый location. *) Исправление: утечки сокетов при использовании HTTP/2 и подзапросов в модуле njs. -- Maxim Dounin http://nginx.org/ ___ nginx-ru-announce mailing list nginx-ru-announce@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru-announce
nginx-1.19.3
Изменения в nginx 1.19.3 29.09.2020 *) Добавление: модуль ngx_stream_set_module. *) Добавление: директива proxy_cookie_flags. *) Добавление: директива userid_flags. *) Исправление: расширение управления кэшированием stale-if-error ошибочно применялось, если бэкенд возвращал ответ с кодом 500, 502, 503, 504, 403, 404 или 429. *) Исправление: если использовалось кэширование и бэкенд возвращал ответы с строкой заголовка Vary, в логах могли появляться сообщения "[crit] cache file ... has too long header". *) Изменение: при использовании OpenSSL 1.1.1 в логах могли появляться сообщения "[crit] SSL_write() failed". *) Исправление: в логах могли появляться сообщения "SSL_shutdown() failed (SSL: ... bad write retry)"; ошибка появилась в 1.19.2. *) Исправление: при использовании HTTP/2 в рабочем процессе мог произойти segmentation fault, если ошибки с кодом 400 с помощью директивы error_page перенаправлялись в проксируемый location. *) Исправление: утечки сокетов при использовании HTTP/2 и подзапросов в модуле njs. -- Maxim Dounin http://nginx.org/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: статический контент и NodeJS Express
вт, 29 сент. 2020 г. в 12:11, Cyril Zlachevsky :
> спасибо за помощь, все заработало как надо, с небольшими изменениями -
> в строке конфига nginx
> root root /var/www/path/to/static;
> не нужно указывать в конце static, иначе nginx будет добавлять static
> два раза в запрос и не находить запрашиваемый файл:
> 2020/09/29 09:21:30 [error] 1530#1530: *179 open()
>
> "home/user/src/nodejs-app/public/static/static/paintings/ekGLnI-1601359891434.jpg"
> failed (2: No such file or directory), client: 127.0.0.1, server: ,
> request: "GET /static/paintings/ekGLnI-1601359891434.jpg HTTP/1.1",
> host: "127.0.0.1:8080", referrer:
> "http://127.0.0.1:8080/admin/paintings/16;
>
> В итоге рабочий конфиг у меня получился такой:
> server {
> listen 8080;
> location / {
> proxy_pass http://127.0.0.1:3000;
> }
>
> location /static/ {
> root /home/user/src/nodejs-app/public/;
> }
> }
>
> Осталось как-то проверить, будут ли отклоняться запросы PUT и
> POST-запросы к каталогу public/static, не содержащие кук авторизации -
> эта проверка есть на бек-энде, но я не уверен, сработает ли она в
> текущей связке с nginx.
>
curl -X POST ...
curl -X PUT ...
>
>
> вт, 29 сент. 2020 г. в 08:44, fox :
> >
> > Как уже писали выше, например, так:
> > server {
> > location / {
> > proxy_pass http://127.0.0.1:3000;
> > }
> >
> > location /public/static/ {
> > root /var/www/path/to/static;
> > }
> > }
> >
> > 29.09.2020 12:14, Cyril Zlachevsky пишет:
> > > В middleware NextJS каталог public прописан как protected:
> > > protected generatePublicRoutes(): Route[] {
> > >
> > > Авторизация требуется только на загрузку файлов в данный каталог через
> > > запросы PUT и POST и реализована в Express.
> > > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и
> > > динамический контент отдавал ему (на порт 3000 например), а работу со
> > > статикой брал на себя.
> > > Как этот функционал реализовать?
> > >
> > > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin :
> > >>
> > >> Express действительно любит кэшировать состояния (правда это больше
> касается шаблонов — он их компилирует и больше не проверяет, но слышать про
> файлы такое удивительно, возможно используемое раздающее middleware
> придерживается другой политики)
> > >>
> > >
> > >> обычная практика в таких случаях:
> > >>
> > >> выделение «датахранилки» — папки, которую через настроенный location
> раздаёт nginx напрямую
> > >> с кэшами (заголовки и настройки добавить по вкусу)
> > >> https://nginx.org/ru/docs/beginners_guide.html#static
> > >>
> > >> вся статика складывается туда, и нет смысла грузить backend
> непрофильными запросами вообще — nginx отстреляется лучше всего
> > >>
> > >> если каким-то файлам требуется авторизация, можно сделать
> дополнительный internal location и с backend после проверки кидать туда
> (через x-accel-redirect —
> https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/)
> > >> и nginx опять таки отдаст статику напрямую и быстрее любой backend
> логики
> > >>
> > >> более того, можно сделать, чтобы правильна работала отдача частичного
> контента (bytes range) и эффективная раздача с диска
> > >>
> > >> всё что не попадает под пути хранилки проксировать на Express
> > >>
> > >> On 28 Sep 2020, at 20:08, Cyril Zlachevsky <
> cyril.zlachev...@gmail.com> wrote:
> > >>
> > >> Есть приложение на NodeJS, которое прекрасно работает в
> > >> developer-режиме. В качестве http-сервера используется ExpressJS.
> > >> В production-режиме появляется проблема - http GET запросы возвращают
> > >> 404-ю ошибку для всех новых файлов, загруженных после старта
> приложения
> > >> в каталог public.
> > >>
> > >> Пример: если до старта файл public/static/old.jpg существовал, GET
> > >> запрос вернет его с кодом 200.
> > >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg
> > >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение,
> > >> GET на public/static/new.jpg будет возвращать 200.
> > >>
> > >> Гугление проблемы привело к пониманию, что это не ошибка, а
> особенность
> > >> Express-сервера и для production рекомендуется использовать связку
> > >> nginx+express. Как мне настроить работу этой связки, я не вполне
> > >> представляю, поэтому прошу помощи здесь.
> ___
> 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: статический контент и NodeJS Express
спасибо за помощь, все заработало как надо, с небольшими изменениями -
в строке конфига nginx
root root /var/www/path/to/static;
не нужно указывать в конце static, иначе nginx будет добавлять static
два раза в запрос и не находить запрашиваемый файл:
2020/09/29 09:21:30 [error] 1530#1530: *179 open()
"home/user/src/nodejs-app/public/static/static/paintings/ekGLnI-1601359891434.jpg"
failed (2: No such file or directory), client: 127.0.0.1, server: ,
request: "GET /static/paintings/ekGLnI-1601359891434.jpg HTTP/1.1",
host: "127.0.0.1:8080", referrer:
"http://127.0.0.1:8080/admin/paintings/16;
В итоге рабочий конфиг у меня получился такой:
server {
listen 8080;
location / {
proxy_pass http://127.0.0.1:3000;
}
location /static/ {
root /home/user/src/nodejs-app/public/;
}
}
Осталось как-то проверить, будут ли отклоняться запросы PUT и
POST-запросы к каталогу public/static, не содержащие кук авторизации -
эта проверка есть на бек-энде, но я не уверен, сработает ли она в
текущей связке с nginx.
вт, 29 сент. 2020 г. в 08:44, fox :
>
> Как уже писали выше, например, так:
> server {
> location / {
> proxy_pass http://127.0.0.1:3000;
> }
>
> location /public/static/ {
> root /var/www/path/to/static;
> }
> }
>
> 29.09.2020 12:14, Cyril Zlachevsky пишет:
> > В middleware NextJS каталог public прописан как protected:
> > protected generatePublicRoutes(): Route[] {
> >
> > Авторизация требуется только на загрузку файлов в данный каталог через
> > запросы PUT и POST и реализована в Express.
> > И насколько я представляю задачу, нужно, чтобы nginx знал об Express и
> > динамический контент отдавал ему (на порт 3000 например), а работу со
> > статикой брал на себя.
> > Как этот функционал реализовать?
> >
> > пн, 28 сент. 2020 г. в 21:07, Alexey Galygin :
> >>
> >> Express действительно любит кэшировать состояния (правда это больше
> >> касается шаблонов — он их компилирует и больше не проверяет, но слышать
> >> про файлы такое удивительно, возможно используемое раздающее middleware
> >> придерживается другой политики)
> >>
> >
> >> обычная практика в таких случаях:
> >>
> >> выделение «датахранилки» — папки, которую через настроенный location
> >> раздаёт nginx напрямую
> >> с кэшами (заголовки и настройки добавить по вкусу)
> >> https://nginx.org/ru/docs/beginners_guide.html#static
> >>
> >> вся статика складывается туда, и нет смысла грузить backend непрофильными
> >> запросами вообще — nginx отстреляется лучше всего
> >>
> >> если каким-то файлам требуется авторизация, можно сделать дополнительный
> >> internal location и с backend после проверки кидать туда (через
> >> x-accel-redirect —
> >> https://www.nginx.com/resources/wiki/start/topics/examples/x-accel/)
> >> и nginx опять таки отдаст статику напрямую и быстрее любой backend логики
> >>
> >> более того, можно сделать, чтобы правильна работала отдача частичного
> >> контента (bytes range) и эффективная раздача с диска
> >>
> >> всё что не попадает под пути хранилки проксировать на Express
> >>
> >> On 28 Sep 2020, at 20:08, Cyril Zlachevsky
> >> wrote:
> >>
> >> Есть приложение на NodeJS, которое прекрасно работает в
> >> developer-режиме. В качестве http-сервера используется ExpressJS.
> >> В production-режиме появляется проблема - http GET запросы возвращают
> >> 404-ю ошибку для всех новых файлов, загруженных после старта приложения
> >> в каталог public.
> >>
> >> Пример: если до старта файл public/static/old.jpg существовал, GET
> >> запрос вернет его с кодом 200.
> >> Если мы загрузили через nodejs-приложение файл public/static/new.jpg
> >> GET-запрос будет возвращать ошибку 404. Если перезапустить приложение,
> >> GET на public/static/new.jpg будет возвращать 200.
> >>
> >> Гугление проблемы привело к пониманию, что это не ошибка, а особенность
> >> Express-сервера и для production рекомендуется использовать связку
> >> nginx+express. Как мне настроить работу этой связки, я не вполне
> >> представляю, поэтому прошу помощи здесь.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
