Re: Gzip и ETag

[Илья Шипицин <chipitsine@xxxxxxxxx>]

это бред, бред и еще сто раз бред.

если вы точно уверены, что контент кешируемый, добавляете на него
Expire (или max-age, как нравится) и у браузера уже есть копия
контента, про которую он точно знает, что она актуальна. в этом случае
браузер начинает отрисовывать страницу сразу же.

если вы знаете, что контент неизменяемый, но не отдали Expire, то у
браузера есть некая копия контента, про которую он не уверен. Он
сделает ЛИШНИЙ запрос (это время) с заголовком
If-Modified-Since/If-None-Match и только после этого начнет
отрисовывать страницу.

и в каком месте здесь "UI responsiveness" ?


чем гоняться за ETag-ами, лучше сделать правильный Expire.



генерация уникальных имен для CSS делается на стороне приложения. это
проработанная тема, если у вас Ruby On Rails, например, вот так
http://code.google.com/p/bundle-fu/


да, идея простая - уменьшить количество запросов и сделать уникальный
хеш для статических сборок.


необязательно вообще всё навешивать на nginx.



8 мая 2013 г., 17:21 пользователь Anatoly Mikhailov <anatoly@xxxxxxxxx> написал:
>
> On May 8, 2013, at 11:49 AM, Илья Шипицин <chipitsine@xxxxxxxxx> 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 <anatoly@xxxxxxxxx> 
>> написал:
>>>
>>> On May 8, 2013, at 10:34 AM, Maxim Dounin <mdounin@xxxxxxxxxx> 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 <mdounin@xxxxxxxxxx> 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@xxxxxxxxx
>>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>>
>>> _______________________________________________
>>> nginx-ru mailing list
>>> nginx-ru@xxxxxxxxx
>>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>> _______________________________________________
>> nginx-ru mailing list
>> nginx-ru@xxxxxxxxx
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru