Re: Некорректный ответ при использовании fastcgi cache background update on

[Gena Makhomed]

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: 00005594C08CB288
>> 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, 00005594C08CB308, 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