Re: Bug – 304 status - Cache-Control

[Gena Makhomed]

On 07.01.2014 13:16, S.A.N wrote:

>> так что Ваш вариант
>>
>> fastcgi_cache_methods GET HEAD;
>> fastcgi_cache_key "$host$uri$is_args$args";
>>
>> не оптимален, включает $uri$is_args$args вместо $request_uri
>> и даже ошибочен, потому что не включает в себя $request_method.
>
> HEAD кэширует ответ с телом, отдаёт - без.

только что проверил, да, действительно.
на клиенте делаю запрос HEAD, nginx "на лету"
преобразовывает его в запрос GET и отправляет на backend
запрос GET, ответ на который потом и попадает в кеш nginx,
а клиенту nginx отправляет ответ на запрос HEAD, без тела.

если выключить кеширование на стороне nginx, тогда эта "магия"
пропадает и на backend уходит запрос HEAD без преобразования.

а вот для протокола WebDAV до сих пор
приходится вручную workaround`ы делать:

   set $fixed_destination $http_destination;
   if ( $http_destination ~* ^https(.*)$ )
   {
      set $fixed_destination http$1;
   }
   proxy_set_header Destination $fixed_destination;

> Не хотел обидеть автора статьи, я думаю он ещё в 2010 году понял что написал
> что-то не то, после критики статьи Игорем Сысуевым
> http://mailman.nginx.org/pipermail/nginx-ru/2010-June/034696.html

     *) Bugfix: the "If-Modified-Since", "If-Range", etc. client request
        header lines were passed to FastCGI-server while caching.

появился в nginx 0.8.40 аж 07 Jun 2010, а статья написана в 2009 году.

наверное поэтому "где она оправдано применяется в FastCGI",
то есть других вариантов бороться с отдачей 304 пустых страниц
при связи с бекендом по протоколу FastCGI тогда просто не было.

Да, та статья 2009 года сейчас уже достаточно сильно
морально устарела и требует основательного обновления.

Но других статей, о том как настроить кеширование в nginx - просто нет.

> Насчет написать мне свою статью, Вы правы на русском языке очень мало
> достойного материала про Nginx.

> Я не считаю себя хорошим писателем, но когда Nginx реализует ревалидацию по
> ETag, после её внедрения я бы мог написать статью посвященную вопросам
> ревалидации кеша в Nginx.

Торг здесь не уместен. Можно написать статью и без ревалидации по ETag.

Как реализовать ревалидацию по ETag, если его просто не будет у части
клиентов. В кеше ведь всегда находится только один вариант контента -
или сжатый gzip, или uncompressed. А в кешах у клиентов - в общем случае
встречаются оба этих варианта. Делать ревалидацию по If-None-Match
потом будет только та половина клиентов, которой больше повезло.

> Но это далекое будущее, сейчас меня больше интересует почему тот же Squid
> прокси не удаляет клиенские заголовки кеширования и сам не кешит ответ в 304
> статусе и это все без спец конфига под каждый сайт :)

squid - это forward proxy, а nginx - web server. что ж тут не ясного...

-- 
Best regards,
  Gena