> Обращаю внимание - выше написано _с_отдельными_переменными_. Это важно.
> Ну или вообще выкинуть переменные из конструкции, насколько я
> понимаю - они тут не нужны, достаточно соответствующие
> 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 [debug
> Вопрос не в том, что используется в ключе кэширования, а в том,
> что отправляется на бэкенд. И на бэкенд у вас при перезаписи как
> раз отправляется $handler, установленный в другом подзапросе:
> 2018/04/09 21:29:34 [debug] 16867#16867: *1901 fastcgi param:
"PATH_TRANSLATED: /var/www/site/www
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.ng
> Наиболее вероятную причину я озвучил тут:
> 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 16, 2018 at 01:50:12PM -0400, gz wrote:
> Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки?
> От меня требуется пример конфигурации или лога достаточно для выявления
> причины перезаписи файла кэша основного запроса из подзапроса?
>
> Всё корректно работает
Коллеги, каковы дальнейшие действия, чтобы исправить причину ошибки?
От меня требуется пример конфигурации или лога достаточно для выявления
причины перезаписи файла кэша основного запроса из подзапроса?
Всё корректно работает при схеме request → SSI subrequest, но ломается при
background subreque
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;
keep
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: *339
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] 2957
> Попробуйте включить 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:104857
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
__
Добрый вечер.
При использовании fastcgi_cache_background_update наблюдаю странное
поведение nginx.
Адрес недоступен, в кэше лежит ответ со статусом 404.
По истечении времени жизни кэша вместо обращения к апстриму и сохранения
ответа со статусом 404 в кэш и отдачи его клиенту выдаётся ответ нулево
18 matches
Mail list logo
