Re: Некорректный ответ при использовании fastcgi cache background update on
> Обращаю внимание - выше написано _с_отдельными_переменными_. Это важно. > Ну или вообще выкинуть переменные из конструкции, насколько я > понимаю - они тут не нужны, достаточно соответствующие > fastcgi_param задать явно. Ясно. С переменными удобно включать один файл, конструкции установки переменных окружения получаются компактнее. Про кэширование значений map без volatile знал, а вот о возможном кэширование rewrite-переменных не задумывался. Переделал на прямую установку fastcgi_param, пока перезапись не повторяется. Буду наблюдать. Благодарю за помощь! Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279527#msg-279527 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello!
On Tue, Apr 17, 2018 at 12:17:29PM -0400, gz wrote:
> > Это не подзапрос баннера. Это подзапрос
> > fastcgi_cache_background_update. Но в нём используются те же
> > переменные, что уже перезаписаны подзапросом баннера, и в
> > результате на бэкенд уходит неправильное значение переменной
> > PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в
> > соответствии с этим неправильным значением.
>
> Вот теперь, кажется, понимаю.
> Фоновый подзапрос обновления всей страницы получает переопределённые
> переменные окружения и вместо генерации страницы генерирует пустой баннер,
> который сохраняется в кэш.
>
> > Наиболее простое решение - использовать отдельный location для
> > баннеров с отдельными же переменными.
>
> Так и сделано
> (https://forum.nginx.org/read.php?21,279356,279363#msg-279363):
> location /banner/ {
> internal;
>
> fastcgi_cache banner;
> fastcgi_cache_valid 200 24h;
> fastcgi_cache_key '$uri$is_args$args';
>
> set $handler banner.html;
> set $querystring $args;
Обращаю внимание - выше написано _с_отдельными_переменными_. Это
важно.
Ну или вообще выкинуть переменные из конструкции, насколько я
понимаю - они тут не нужны, достаточно соответствующие
fastcgi_param задать явно.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
> Это не подзапрос баннера. Это подзапрос
> fastcgi_cache_background_update. Но в нём используются те же
> переменные, что уже перезаписаны подзапросом баннера, и в
> результате на бэкенд уходит неправильное значение переменной
> PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в
> соответствии с этим неправильным значением.
Вот теперь, кажется, понимаю.
Фоновый подзапрос обновления всей страницы получает переопределённые
переменные окружения и вместо генерации страницы генерирует пустой баннер,
который сохраняется в кэш.
> Наиболее простое решение - использовать отдельный location для
> баннеров с отдельными же переменными.
Так и сделано
(https://forum.nginx.org/read.php?21,279356,279363#msg-279363):
location /banner/ {
internal;
fastcgi_cache banner;
fastcgi_cache_valid 200 24h;
fastcgi_cache_key '$uri$is_args$args';
set $handler banner.html;
set $querystring $args;
fastcgi_param REQUEST_URI $uri$is_args$args;
fastcgi_param SCRIPT_NAME $uri$is_args$args;
fastcgi_param PATH_INFO $uri$is_args$args;
include parser;
fastcgi_pass fcgiwrap;
}
> Наиболее правильное -
> переписать логику так, чтобы нужные бэкенду значения вычислялись
> не с помощью set, а с помощью map { volatile; ... }.
Ясно, значения не будут кэшироваться и можно будет получить корректные
переменные окружения для каждого подзапроса.
Спасибо, попробую.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279356,279490#msg-279490
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello!
On Mon, Apr 16, 2018 at 04:52:20PM -0400, gz wrote:
> > Вопрос не в том, что используется в ключе кэширования, а в том,
> > что отправляется на бэкенд. И на бэкенд у вас при перезаписи как
> > раз отправляется $handler, установленный в другом подзапросе:
>
> > 2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param:
> "PATH_TRANSLATED: /var/www/site/www/banner.html"
>
> Не совсем понимаю как результат работы подзапроса, пусть и с перезаписанными
> переменными окружения, может быть помещён в кэш основного запроса.
> Если кэши запроса и подзапроса разные (разные cache_path) да к тому же
> используют разные ключи кэширования.
> То есть, подзапрос баннера вдруг перезаписывает ответ всей страницы.
Это не подзапрос баннера. Это подзапрос
fastcgi_cache_background_update. Но в нём используются те же
переменные, что уже перезаписаны подзапросом баннера, и в
результате на бэкенд уходит неправильное значение переменной
PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в
соответствии с этим неправильным значением.
> То, куда попадёт ответ подзапроса зависит от PATH_TRANSLATED?
Нет. Он неё зависит, что у вас отвечает бэкенд.
> > Бэкенд возвращает пустой ответ, и этот ответ попадает в кэш. То
> > есть всё ровно так, как я и предполагал. Нужно исправлять
> > конфигурацию так, чтобы запрос на бэкенд не использовал
> > переменных, которые могут быть переписаны другими подзапросами.
>
> Не уверен, что это возможно.
> FCGI-приложение требует этих переменных для своей работы.
Наиболее простое решение - использовать отдельный location для
баннеров с отдельными же переменными. Наиболее правильное -
переписать логику так, чтобы нужные бэкенду значения вычислялись
не с помощью set, а с помощью map { volatile; ... }.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
> Вопрос не в том, что используется в ключе кэширования, а в том, > что отправляется на бэкенд. И на бэкенд у вас при перезаписи как > раз отправляется $handler, установленный в другом подзапросе: > 2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param: "PATH_TRANSLATED: /var/www/site/www/banner.html" Не совсем понимаю как результат работы подзапроса, пусть и с перезаписанными переменными окружения, может быть помещён в кэш основного запроса. Если кэши запроса и подзапроса разные (разные cache_path) да к тому же используют разные ключи кэширования. То есть, подзапрос баннера вдруг перезаписывает ответ всей страницы. То, куда попадёт ответ подзапроса зависит от PATH_TRANSLATED? > Бэкенд возвращает пустой ответ, и этот ответ попадает в кэш. То > есть всё ровно так, как я и предполагал. Нужно исправлять > конфигурацию так, чтобы запрос на бэкенд не использовал > переменных, которые могут быть переписаны другими подзапросами. Не уверен, что это возможно. FCGI-приложение требует этих переменных для своей работы. > Вы пишите в список рассылки. Ясно, изучу. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279467#msg-279467 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello! On Mon, Apr 16, 2018 at 03:17:36PM -0400, gz wrote: > > Наиболее вероятную причину я озвучил тут: > > http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html > > Если предположение верно, то исправлять нужно конфигурацию. > > Я спустя двадцать минут ответил — > https://forum.nginx.org/read.php?21,279356,279365#msg-279365 А, то есть форум промотал не мой ответ, а ответ на него. Разница, впрочем, небольшая. > Не думаю, что дело в переменных $handler и $querystring они в ключе > кэширования не используются. Вопрос не в том, что используется в ключе кэширования, а в том, что отправляется на бэкенд. И на бэкенд у вас при перезаписи как раз отправляется $handler, установленный в другом подзапросе: 2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param: "PATH_TRANSLATED: /var/www/site/www/banner.html" Бэкенд возвращает пустой ответ, и этот ответ попадает в кэш. То есть всё ровно так, как я и предполагал. Нужно исправлять конфигурацию так, чтобы запрос на бэкенд не использовал переменных, которые могут быть переписаны другими подзапросами. [...] > > (А, ну и судя по всему форум опять промотал письмо. Не пользуйтесь им, мы > не просто так выпилили на него ссылки с nginx.org.) > > К сожалению, иными способами пользоваться этим форумом я не умею. Вы пишите в список рассылки. Пишете в него напрямую, не надо для это пользоваться горе-поделками любителей форумов. Подписаться можно тут: http://nginx.org/ru/support.html -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
> Наиболее вероятную причину я озвучил тут: > http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html > Если предположение верно, то исправлять нужно конфигурацию. Я спустя двадцать минут ответил — https://forum.nginx.org/read.php?21,279356,279365#msg-279365 Не думаю, что дело в переменных $handler и $querystring они в ключе кэширования не используются. В ключе кэширования используется $uri, который, как известно, в SSI-подзапросе не равен $request_uri, а указывает на URI подзапроса. И пока дело не доходит до фонового обновления кэша всё в порядке. Но, перезапись происходит ещё и в другой cache_path! Основной запрос использует путь /cache/pages/, а SSI-подзапрос использует путь /cache/banners/. И последний умудряется перезаписать файл первого. Думаю, что это всё же ошибка в nginx, а не в моей конфигурации. > (А, ну и судя по всему форум опять промотал письмо. Не пользуйтесь им, мы не просто так выпилили на него ссылки с nginx.org.) К сожалению, иными способами пользоваться этим форумом я не умею. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279465#msg-279465 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello! On Mon, Apr 16, 2018 at 01:50:12PM -0400, gz wrote: > Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки? > От меня требуется пример конфигурации или лога достаточно для выявления > причины перезаписи файла кэша основного запроса из подзапроса? > > Всё корректно работает при схеме request → SSI subrequest, но ломается при > background subrequest → SSI subrequest. Наиболее вероятную причину я озвучил тут: http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html Если предположение верно, то исправлять нужно конфигурацию. (А, ну и судя по всему форум опять промотал письмо. Не пользуйтесь им, мы не просто так выпилили на него ссылки с nginx.org.) -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки? От меня требуется пример конфигурации или лога достаточно для выявления причины перезаписи файла кэша основного запроса из подзапроса? Всё корректно работает при схеме request → SSI subrequest, но ломается при background subrequest → SSI subrequest. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279356,279463#msg-279463 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello!
On Mon, Apr 09, 2018 at 03:09:39PM -0400, gz wrote:
> > Судя по приведённому debug log'у, в кэше лежит валидный ответ
> > бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
> > клиенту.
>
> > Очевидно, что ответ этот nginx не сам придумал, а получил от
> > бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть
> > в debug log'е в тот момент, когда это произошло.
>
> Понемногу картина проясняется.
> Ответ действительно генерирует приложение, но это не основной бэкенд, а
> бэкенд для SSI-вставки баннеров.
>
> У меня были подозрения, что подзапрос на фоновое обновление кэша уходит
> куда-то не туда и они подтвердились.
> Добавил метку при генерации ответа и вижу её в файле кэша, когда вместо 404
> начинает отдаваться 200.
>
> Отдача баннеров производится из отдельного internal-локейшна, который
> вызывается только при обработке SSI.
> На странице 404 есть SSI баннеров.
> Баннеры кэшируются отдельно, у них не только своя директория кэша, но и свой
> ключ:
> fastcgi_cache_path /var/www/site/cache/banners levels=
> keys_zone=banner:5minactive=1m max_size=5m;
> …
> location /banner/ {
> internal;
>
> fastcgi_cache banner;
> fastcgi_cache_valid 200 24h;
> fastcgi_cache_key '$uri$is_args$args';
>
> set $handlerbanner.html;
> set $querystring$args;
>
> fastcgi_param REQUEST_URI $uri$is_args$args;
> fastcgi_param SCRIPT_NAME $uri$is_args$args;
> fastcgi_param PATH_INFO $uri$is_args$args;
>
> include parser;
> fastcgi_passfcgiwrap;
> }
>
> Могу лишь предположить, что подзапрос фонового обновления кэша наследует
> fastcgi_cache_path и fastcgi_cache_key от основного запроса, а значения,
> указанные в соответствующем локейшне, игнорируются, что приводит к
> перезаписи содержимого кэша.
>
> Памятуя о сохранении request_uri в подзапросах, специально использую в ключе
> кэша подзапроса $uri.
А как используются переменные $handler и $querystring?
Потому что в подзапросах и основном запросе пространство
переменных общее, отличаются только значения, получаемые
непосредственно из запроса, как например $uri и $args. И
соответственно после выполнения подзапроса в /banner/ - переменная
$handler в основном запросе в том числе будет иметь значение
"banner.html". Если потом эта переменная как-то передаются на
бэкенд, и на основании их генерируется ответ - то результат будет
именно такой, как у вас получается, потому что в момент создания
запроса на бэкенд для обновления кэша у переменной будет значение
"banner.html".
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
> Судя по приведённому debug log'у, в кэше лежит валидный ответ
> бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
> клиенту.
> Очевидно, что ответ этот nginx не сам придумал, а получил от
> бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть
> в debug log'е в тот момент, когда это произошло.
Понемногу картина проясняется.
Ответ действительно генерирует приложение, но это не основной бэкенд, а
бэкенд для SSI-вставки баннеров.
У меня были подозрения, что подзапрос на фоновое обновление кэша уходит
куда-то не туда и они подтвердились.
Добавил метку при генерации ответа и вижу её в файле кэша, когда вместо 404
начинает отдаваться 200.
Отдача баннеров производится из отдельного internal-локейшна, который
вызывается только при обработке SSI.
На странице 404 есть SSI баннеров.
Баннеры кэшируются отдельно, у них не только своя директория кэша, но и свой
ключ:
fastcgi_cache_path /var/www/site/cache/banners levels=
keys_zone=banner:5minactive=1m max_size=5m;
…
location /banner/ {
internal;
fastcgi_cache banner;
fastcgi_cache_valid 200 24h;
fastcgi_cache_key '$uri$is_args$args';
set $handlerbanner.html;
set $querystring$args;
fastcgi_param REQUEST_URI $uri$is_args$args;
fastcgi_param SCRIPT_NAME $uri$is_args$args;
fastcgi_param PATH_INFO $uri$is_args$args;
include parser;
fastcgi_passfcgiwrap;
}
Могу лишь предположить, что подзапрос фонового обновления кэша наследует
fastcgi_cache_path и fastcgi_cache_key от основного запроса, а значения,
указанные в соответствующем локейшне, игнорируются, что приводит к
перезаписи содержимого кэша.
Памятуя о сохранении request_uri в подзапросах, специально использую в ключе
кэша подзапроса $uri.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279356,279363#msg-279363
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
> Причина в том, что в документации для директивы fastcgi_cache_key
> указано некорректное с точки зрения протокола HTTP значение
> localhost:9000$request_uri - так оно нормально работать не будет.
Я использую сокет:
upstream fcgiwrap {
serverunix:/var/run/fcgiwrap.socket;
keepalive 32;
}
…
fastcgi_pass fcgiwrap;
> Пока что существует только один workaround:
> добавить $request_method в fastcgi_cache_key
> Например, вот так:
> fastcgi_cache_key "$request_method $scheme://$host$request_uri";
Именно для того, чтобы разные HTTP-методы не перезаписывали кэш я использую
такой ключ:
fastcgi_cache_key
'$scheme|$request_method|$http_if_none_match|$http_vary|$http_x_requested_with|$request_uri';
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279356,279362#msg-279362
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
On 09.04.2018 21:08, Maxim Dounin wrote: 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0 e:1 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file: "/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: 5594C08CB288 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52, 5594C08CB308, 475, 0 [...] 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record length: 74 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Content-Type: text/html; charset=UTF-8" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Status: 200" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: "Content-Length: 0" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 1 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header done 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache send: /var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 HTTP/1.1 200 [...] Судя по приведённому debug log'у, в кэше лежит валидный ответ бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся клиенту. Очевидно, что ответ этот nginx не сам придумал, а получил от бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть в debug log'е в тот момент, когда это произошло. С бэкендом все нормально. Это глюк на стороне nginx. Такой глюк происходит в том случае, когда из интернета на сайт отправляется запрос HEAD - есть очень много роботов, которые сначала отправляют HEAD запрос, и потом только делают нормальный GET запрос. Причина в том, что в документации для директивы fastcgi_cache_key указано некорректное с точки зрения протокола HTTP значение localhost:9000$request_uri - так оно нормально работать не будет. Даже если добавить туда $scheme и $host, например, так: fastcgi_cache_key "$scheme://$host$request_uri"; - этот глюк с пустыми ответами все равно останется. Пока что существует только один workaround: добавить $request_method в fastcgi_cache_key Например, вот так: fastcgi_cache_key "$request_method $scheme://$host$request_uri"; Подозреваю что сейчас в интернете есть очень много сайтов, которые используют модуль fastcgi, на которых включено кеширование в nginx и значение директивы fastcgi_cache_key скопировано из документации. Идеальным вариантом решения проблемы было бы добавление директивы fastcgi_cache_convert_head со значением "on" по умолчанию, по аналогии с имеющейся директивой proxy_cache_convert_head. -- Best regards, Gena ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello! On Mon, Apr 09, 2018 at 01:43:33PM -0400, gz wrote: > > Попробуйте включить debug log в nginx'е, возможно происходящее > станет понятнее. > > Понятнее не стало. [...] > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0 > e:1 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file: > "/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49" > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: > 5594C08CB288 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52, 5594C08CB308, > 475, 0 [...] > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record length: > 74 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: > "Content-Type: text/html; charset=UTF-8" > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: > "Status: 200" > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 0 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header: > "Content-Length: 0" > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi parser: 1 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi header done > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache send: > /var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49 > 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 HTTP/1.1 200 [...] Судя по приведённому debug log'у, в кэше лежит валидный ответ бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся клиенту. Очевидно, что ответ этот nginx не сам придумал, а получил от бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть в debug log'е в тот момент, когда это произошло. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
> Попробуйте включить debug log в nginx'е, возможно происходящее станет понятнее. Понятнее не стало. - 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 using configuration "/" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http cl:-1 max:104857600 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 rewrite phase: 3 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post rewrite phase: 4 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 5 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 6 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 7 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 8 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 9 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 10 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post access phase: 11 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 12 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 try files handler 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 trying to use file: "@backend" "/var/www/site/www@backend" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 test location: "@backend" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 using location: @backend "/missing/?" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 rewrite phase: 3 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script value: "_ind.html" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script set $handler 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script complex value 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "_action=" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "/missing/" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "&" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script set $querystring 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post rewrite phase: 4 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 5 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 6 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 7 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 8 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 9 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 access phase: 10 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 post access phase: 11 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 12 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 generic phase: 13 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http init upstream, client timer: 0 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 epoll add event: fd:51 op:3 ev:80002005 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map started 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "http" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "GET" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "/missing/" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http cache key: "http|GET/missing/" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map started 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "/missing/" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map started 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script copy: "|" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map: "||" "" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http map: "/missing/" "" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http script var: "" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: 5594C08CB230 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache exists: 0 e:1 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 cache file: "/var/www/site/cache/pages/49/1d/2756424aaf76d1f24c982e863d611d49" 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 add cleanup: 5594C08CB288 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http file cache fd: 52 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 read: 52, 5594C08CB308, 475, 0 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http upstream cache: 0 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 posix_memalign: 5594C08CB660:4096 @16 2018/04/09 18:21:23 [debug] 29576#29576: *3395329 http fastcgi record b
Re: Некорректный ответ при использовании fastcgi cache background update on
Hello! On Sun, Apr 08, 2018 at 08:54:12PM -0400, gz wrote: > Что характерно, при этом до апстрима запрос вообще не доходит. > Включил логирование в приложении: смену статуса в логе nginx вижу, генерации > ответа fastcgi-приложением не происходит. Попробуйте включить debug log в nginx'е, возможно происходящее станет понятнее. Подробнее тут: http://nginx.org/ru/docs/debugging_log.html Кроме того, имеет смысл показать полную минимальную конфигурацию, с которой воспроизводится проблема. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Некорректный ответ при использовании fastcgi cache background update on
Что характерно, при этом до апстрима запрос вообще не доходит. Включил логирование в приложении: смену статуса в логе nginx вижу, генерации ответа fastcgi-приложением не происходит. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,279350,279351#msg-279351 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
