Re: Gzip и ETag

[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