ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug ? 304 status - Cache-Control



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

_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.