On 08.05.2013, at 13:08, Илья Шипицин <chipits...@gmail.com> wrote:
> Если Expire уже правильный, то для динамического контента вы все равно > сгенерируете страницу (независимо от ETag-ов), а за статическим > контентом браузер второй раз не придет. > > то есть проблем нет вообще никаких. наличие ETag-а (или его > отсутствие) роли не играют. что вы так привязались к Expire, если тред о ConditionalGet. > > да, компоновщиков статики много. и они делают примерно одно и то же. > делают весьма хорошо. а что тут можно придумать нового, конечно, одно и тоже. > > 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 _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
