Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Gzip и ETag
расскажите более подробно про сценарии, когда необходим именно ETag ?
по моим наблюдениям большинство браузеров используют
If-Not-Modified-Since, и небольшая часть - одновременно
If-Not-Modified-Since и ETag.
с другой стороны, если контент заведомо статический, отдаем его с
"Cache-Control: max-age=много-много" и избавляемся от 304-х кодов
почти полностью.
какой великий смысл в том, чтобы отдать статику, не указав при этом
длинный Expire (или max-age), чтобы браузер делал лишний запрос "не
обновилась ли картинка/стиль/скрипт" ?
если вы добиваетесь именно "UI responsiveness", логично вообще
избавляться от If-None-Match/If-Not-Modified-Since запросов, благо это
не так сложно.
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
|
