Re: Gzip и ETag

Thu May 9 00:13:19 UTC 2013

On 08.05.2013, at 13:08, Илья Шипицин <chipitsine at gmail.com> wrote:

> Если Expire уже правильный, то для динамического контента вы все равно
> сгенерируете страницу (независимо от ETag-ов), а за статическим
> контентом браузер второй раз не придет.
> 
> то есть проблем нет вообще никаких. наличие ETag-а (или его
> отсутствие) роли не играют.

что вы так привязались к Expire, если тред о ConditionalGet.

> 
> да, компоновщиков статики много. и они делают примерно одно и то же.
> делают весьма хорошо.

а что тут можно придумать нового, конечно, одно и тоже.

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