On May 8, 2013, at 11:49 AM, Илья Шипицин <chipits...@gmail.com> wrote:
> расскажите более подробно про сценарии, когда необходим именно ETag ? > ETag необходим тогда, когда вы точно уверены, что ответ от сервера кэшируем и нет необходимости генерить его заново, когда ваш бэкэнд уверен в этом > по моим наблюдениям большинство браузеров используют > If-Not-Modified-Since, и небольшая часть - одновременно > If-Not-Modified-Since и ETag. эти вещи не жестко связаны, вы можете использовать либо то, либо другое, либо оба вместе, наипростейшая схема работы описана здесь http://www.youtube.com/watch?v=Eq3E6ahEk4k > > с другой стороны, если контент заведомо статический, отдаем его с > "Cache-Control: max-age=много-много" и избавляемся от 304-х кодов > почти полностью. для статики это лучший вариант, для динамики - на усмотрение > > какой великий смысл в том, чтобы отдать статику, не указав при этом > длинный Expire (или max-age), чтобы браузер делал лишний запрос "не > обновилась ли картинка/стиль/скрипт" ? никакого, статика вся должна ложиться в браузерный кэш и не привлекать эвристический анализ > > если вы добиваетесь именно "UI responsiveness", логично вообще > избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это > не так сложно. это не так, ответ 304 избавляет бразузер от рендеринга, если вы точно уверены, что ничего нового нет > > 8 мая 2013 г., 16:18 пользователь Anatoly Mikhailov <anat...@sonru.com> > написал: >> >> On May 8, 2013, at 10:34 AM, Maxim Dounin <mdou...@mdounin.ru> wrote: >> >>> Hello! >>> >>> On Wed, May 08, 2013 at 09:31:32AM +0100, Anatoly Mikhailov wrote: >>> >>>> >>>> On May 8, 2013, at 12:23 AM, Maxim Dounin <mdou...@mdounin.ru> wrote: >>>> >>>>> Hello! >>>>> >>>>> On Tue, May 07, 2013 at 11:32:07PM +0100, Anatoly Mikhailov wrote: >>>>> >>>>>> Меня настораживает интересная закономерность, включая/отключая gzip в >>>>>> конфигурации Nginx, >>>>>> ETag заголовок пропадает/появляется соответственно в прокированном >>>>>> ответе от бэкэнда (Unicorn). >>>>>> Проще говоря, при gzip off ответ всегда приходит с ETag, все остальные >>>>>> параметры на это не влияют. >>>>>> >>>>>> Бэкнэнд, если слушает порт, то легко убедиться, что он добавляет >>>>>> заголовок ETag к каждому ответу, >>>>>> и чтобы проксировать ETag заголовок через upstream приходится выключать >>>>>> gzip. >>>>>> Если я правильно понимаю, то сжатый ответ не может содержать некоторые >>>>>> заголовки? >>>>> >>>>> При любых изменениях тела ответа, в том числе - модулем gzip, >>>>> ETag'и из ответа убираются. Это сделано, т.к. стандарт требует, >>>>> чтобы strong etags у ответов совпадали тогда и только тогда, когда >>>>> ответы совпадают до байта. (А если ответы будет не совпадать при >>>>> одинаковых ETag'ах - это в свою очередь чревато получением >>>>> неверного суммарного ответа при комбинировании нескольких ответов >>>>> на range-запросы.) Почитать подробности можно тут (и далее по >>>>> ссылкам): >>>>> >>>>> http://tools.ietf.org/html/rfc2616#section-3.11 >>>>> >>>> >>>> Ага, спасибо, более менее разобрался. Все таки, есть вариант оставлять >>>> ETag, пришедший от бэкэнда, >>>> может в сочетании с Last-Modified? >>> >>> В чём цель? >> >> Цель всегда одна - UI responsiveness, чем быстрее пользователь получит >> данные (идеально - из браузерного кэша), >> тем меньше нагрузки будет на рендеринг в браузере и можно отдать пустое тело >> запроса от бэкэнда (fresh_when/stale в Rack) >> >> E-Tag, Last-Modified - весьма удобные инструменты, которые неожиданно >> перестали работать как раз после Nginx 1.3.3 :) >> >>> >>>> Кстати, до реализации SPDY все было точно так же (ETag не проксировался >>>> при Gzip)? >>> >>> Поддержка entity tags не имеет отношения к spdy, и появилась в >>> nginx 1.3.3. До этого nginx не знал про заголовок ETag и ничего с >>> ним не делал. >>> >>> -- >>> Maxim Dounin >>> http://nginx.org/en/donation.html >>> >>> _______________________________________________ >>> nginx-ru mailing list >>> nginx-ru@nginx.org >>> http://mailman.nginx.org/mailman/listinfo/nginx-ru >> >> _______________________________________________ >> nginx-ru mailing list >> nginx-ru@nginx.org >> http://mailman.nginx.org/mailman/listinfo/nginx-ru > _______________________________________________ > nginx-ru mailing list > nginx-ru@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx-ru _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
