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
|