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
