<br><br>вторник, 7 января 2014 г. пользователь Gena Makhomed  писал:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 07.01.2014 15:41, Илья Шипицин wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

2) прокидывания клиентских if-none-match/if-not-modified-<u></u>__since<br>
до бекенда<br>
</blockquote></blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
только это как раз будет способ создать проблему, а не решить ее.<br>
backend ответит 304 статусом и пустая страница попадет в кеш nginx.<br>
</blockquote></blockquote>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
если бекенд ответит 304, то nginx тоже ответит 304. да, в этом случае<br>
тело ответа не нужно.<br>
<br>
если бекенд понял, что контент поменялся, то ответ будет 200 и будет тело.<br>
<br>
соответственно, когда тело нужно, оно есть. и наоборот. в чем проблема ?<br>
</blockquote>
<br>
fastcgi_cache_key "$host$uri$is_args$args";<br>
<br>
от backend`а приходит 304 ответ, который говорит nginx`у,<br>
чтобы тот положил ответ в свой кеш на 1 секунду, что nginx и делает.<br>
<br>
и все последующие GET запросы от других клиентов по этому cache_key<br>
будут получать пустую страницу, от закешированного ранее 304 ответа.</blockquote><div><br></div><div>естественно, что нельзя отдавать пустые ответы на get-запросы, которые подразумевают непустое тело. именно в этом и заключается существнное усложнение логики. </div>
<div><br></div><div><br></div><div>нет ничего страшного, что 304 ответы кешатся с пустым телом. проблема в том, что не всегда этот кеш можно использовать (если это ответ, на котрый мы отвечаем 304 - можно).</div><div><br>
</div><div>и, честно, не очень понятно, в целом это будет хорошо или плохо. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
ибо "Cache-Control: public, max-age=1" - backend части последующих<br>
запросов от клиентов просто не увидит, их будет обрабатывать nginx.<br>
<br>
поэтому надо или включать $http_if_modified_since и $http_if_none_match<br>
в *_cache_key (но это плохо) или запретить nginx кешировать 304 ответы.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
соответственно, если хочется и кеш на клиенте включить и кеш nginx<br>
выключить - то управлять этими двумя разными кешами надо backend`у.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 06.01.2014 10:35, S.A.N wrote:<br>
<br>
  Отключить Nginx кеширования тоже не можем потому что на<br>
  других uri мы<br>
  используем Nginx кеширования, например uri<br>
  /news/list<br>
  Отдает контент с заголовками<br>
  Cache-Control: public, max-age=1<br>
  Эта страница должна попадать в кеш Nginx.<br>
  Имино с этой страницей и будут проблемы,<br>
  если в папке кеша Nginx удалится файл кеша,<br>
  и прийдет запрос от браузера с актуальным заголовками<br>
  If-Modified-Since и If-None-Match, на этот запрос бекенд<br>
  ответит 304<br>
  статусом и вернет заговок Cache-Control: public, max-age=1,<br>
  в результате чего 304 ответ попадет в кеш Nginx.<br>
</blockquote>
<br>
-- <br>
Best regards,<br>
 Gena<br>
<br>
______________________________<u></u>_________________<br>
nginx-ru mailing list<br>
<a>nginx-ru@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-ru" target="_blank">http://mailman.nginx.org/<u></u>mailman/listinfo/nginx-ru</a></blockquote>