<div dir="ltr">Спасибо, вырезал Vary - полет нормальный. Вообще странно, что об этом прямо не упомянуто в доке в абзаце про cache_key. Какое-то отдельное знание сейчас.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-09 22:35 GMT+03:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Mon, Nov 09, 2015 at 10:03:42PM +0300, Anton Kuznetsov wrote:<br>
<br>
> Включил логирование Vary - обнаружил ровно два варианта. Четко повторяют<br>
> что передал браузер и соответственно четко следует за моей переменной<br>
> $cache_gzip=0|1-<br>
> вроде бы должно получаться два моих задуманных варианта.<br>
<br>
</span>В заголовке Vary указываются заголовки запроса, от которых зависит<br>
вторичный ключ кеширования.  Т.е. даже при ровно одном варианте,<br>
Vary:<br>
<br>
Vary: Accept-Encoding<br>
<br>
количество возможных варинтов ответов начинает определяеться<br>
количеством возможных значений Accept-Encoding, которые присылает<br>
клиент.<br>
<span class=""><br>
> 2015-11-09 21:54 GMT+03:00 Anton Kuznetsov <<a href="mailto:maybe@arjlover.net">maybe@arjlover.net</a>>:<br>
><br>
> > Но позвольте, зачем тогда нужен ключ кэширования? Я же четко сказал от<br>
> > чего он должен зависить? Почему он зависит еще от чего-то?<br>
<br>
</span>Явно заданный ключ кеширования работает тогда и только тогда,<br>
когда мы заранее знаем, от чего зависит ответ бекенда.  В этом<br>
случае проверку Vary можно выключить, и использовать только явно<br>
заданный ключ.<br>
<br>
Если же результат ответа бекенда заранее не известен, то<br>
приходится пытаться придумывать что-то, что позволило бы бекенду<br>
контролировать процесс.<br>
<br>
В HTTP/1.1 для этого придуман механизм вариативности ресурсов -<br>
ресурс может существовать в нескольких вариантах, и с помощью<br>
заголовка Vary бекенд сообщает о том, от каких именно заголовков<br>
завист, какой вариант будет выбран.  Механизм, скажем так, не<br>
очень, и приводит к ужасному дублированию ресурсов при<br>
кешировании (особенно, если пытаться использовать "Vary:<br>
User-Agent", как некоторые делают), но уж какой есть.  Задачу свою<br>
он, так или иначе, выполняет, и позволяет обеспечить корректность<br>
ответов в общем случае, когда поведение бекенда заранее не<br>
известно.<br>
<br>
Если вам этот механизм не нужен - в nginx'е есть ручка,<br>
позволяющая поддержку этого механизма выключить, и,<br>
соответветственно, явно прописать правила руками.<br>
<br>
Подробнее тут, как уже говорилось, тут:<br>
<div class="HOEnZb"><div class="h5"><br>
<a href="http://nginx.org/r/fastcgi_ignore_headers" rel="noreferrer" target="_blank">http://nginx.org/r/fastcgi_ignore_headers</a><br>
<a href="http://nginx.org/r/fastcgi_cache_valid" rel="noreferrer" target="_blank">http://nginx.org/r/fastcgi_cache_valid</a><br>
<br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
<br>
_______________________________________________<br>
nginx-ru mailing list<br>
<a href="mailto:nginx-ru@nginx.org">nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-ru</a></div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">Best regards,<br>Anton Kuznetsov.       </div>
</div>