Если Expire уже правильный, то для динамического контента вы все равно сгенерируете страницу (независимо от ETag-ов), а за статическим контентом браузер второй раз не придет.
то есть проблем нет вообще никаких. наличие ETag-а (или его отсутствие) роли не играют. да, компоновщиков статики много. и они делают примерно одно и то же. делают весьма хорошо. 8 мая 2013 г., 17:58 пользователь Anatoly Mikhailov <anat...@sonru.com> написал: > > On May 8, 2013, at 12:50 PM, Илья Шипицин <chipits...@gmail.com> wrote: > >> это бред, бред и еще сто раз бред. > > ответ в пустоту, не забывайте указывать контекст > >> >> если вы точно уверены, что контент кешируемый, добавляете на него >> Expire (или max-age, как нравится) и у браузера уже есть копия >> контента, про которую он точно знает, что она актуальна. в этом случае >> браузер начинает отрисовывать страницу сразу же. >> >> если вы знаете, что контент неизменяемый, но не отдали Expire, то у >> браузера есть некая копия контента, про которую он не уверен. Он >> сделает ЛИШНИЙ запрос (это время) с заголовком >> If-Modified-Since/If-None-Match и только после этого начнет >> отрисовывать страницу. >> >> и в каком месте здесь "UI responsiveness" ? >> >> >> чем гоняться за ETag-ами, лучше сделать правильный Expire. >> > > Expire уже везде правильный > >> >> >> генерация уникальных имен для CSS делается на стороне приложения. это >> проработанная тема, если у вас Ruby On Rails, например, вот так >> http://code.google.com/p/bundle-fu/ > > Assets Pipeline делает тоже самое > >> >> >> да, идея простая - уменьшить количество запросов и сделать уникальный >> хеш для статических сборок. >> >> >> необязательно вообще всё навешивать на nginx. >> >> >> >> 8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov <anat...@sonru.com> >> написал: >>> >>> 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 >> _______________________________________________ >> 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
