> Обращаю внимание - выше написано _с_отдельными_переменными_. Это важно.
> Ну или вообще выкинуть переменные из конструкции, насколько я
> понимаю - они тут не нужны, достаточно соответствующие
> fastcgi_param задать явно.
Ясно.
С переменными удобно включать один файл, конструкции установки
Hello!
On Tue, Apr 17, 2018 at 12:17:29PM -0400, gz wrote:
> > Это не подзапрос баннера. Это подзапрос
> > fastcgi_cache_background_update. Но в нём используются те же
> > переменные, что уже перезаписаны подзапросом баннера, и в
> > результате на бэкенд уходит неправильное значение
> Это не подзапрос баннера. Это подзапрос
> fastcgi_cache_background_update. Но в нём используются те же
> переменные, что уже перезаписаны подзапросом баннера, и в
> результате на бэкенд уходит неправильное значение переменной
> PATH_TRANSLATED. И бэкенд, в свою очередь, отвечает на него в
>
Hello!
On Mon, Apr 16, 2018 at 04:52:20PM -0400, gz wrote:
> > Вопрос не в том, что используется в ключе кэширования, а в том,
> > что отправляется на бэкенд. И на бэкенд у вас при перезаписи как
> > раз отправляется $handler, установленный в другом подзапросе:
>
> > 2018/04/09 21:29:34
Hello!
On Mon, Apr 16, 2018 at 03:17:36PM -0400, gz wrote:
> > Наиболее вероятную причину я озвучил тут:
> > http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html
> > Если предположение верно, то исправлять нужно конфигурацию.
>
> Я спустя двадцать минут ответил —
>
> Наиболее вероятную причину я озвучил тут:
> http://mailman.nginx.org/pipermail/nginx-ru/2018-April/061095.html
> Если предположение верно, то исправлять нужно конфигурацию.
Я спустя двадцать минут ответил —
https://forum.nginx.org/read.php?21,279356,279365#msg-279365
Не думаю, что дело в
Hello!
On Mon, Apr 09, 2018 at 03:09:39PM -0400, gz wrote:
> > Судя по приведённому debug log'у, в кэше лежит валидный ответ
> > бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
> > клиенту.
>
> > Очевидно, что ответ этот nginx не сам придумал, а получил от
> > бэкенда.
> Судя по приведённому debug log'у, в кэше лежит валидный ответ
> бэкенда с "Status: 200" и "Content-Length: 0", который и отдаётся
> клиенту.
> Очевидно, что ответ этот nginx не сам придумал, а получил от
> бэкенда. Почему бэкенд прислал именно такой ответ - надо смотреть
> в debug log'е в
> Причина в том, что в документации для директивы fastcgi_cache_key
> указано некорректное с точки зрения протокола HTTP значение
> localhost:9000$request_uri - так оно нормально работать не будет.
Я использую сокет:
upstream fcgiwrap {
serverunix:/var/run/fcgiwrap.socket;
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:
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]
> Попробуйте включить 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
Hello!
On Sun, Apr 08, 2018 at 08:54:12PM -0400, gz wrote:
> Что характерно, при этом до апстрима запрос вообще не доходит.
> Включил логирование в приложении: смену статуса в логе nginx вижу, генерации
> ответа fastcgi-приложением не происходит.
Попробуйте включить debug log в nginx'е,
Что характерно, при этом до апстрима запрос вообще не доходит.
Включил логирование в приложении: смену статуса в логе nginx вижу, генерации
ответа fastcgi-приложением не происходит.
Posted at Nginx Forum:
https://forum.nginx.org/read.php?21,279350,279351#msg-279351
14 matches
Mail list logo
