Re: nginx 1.3.12 SPDY add_headers bug

[Anatoly Mikhailov <anatoly@xxxxxxxxx>]

On 12.02.2013, at 1:49, Maxim Dounin <mdounin@xxxxxxxxxx> wrote:

> Hello!
> 
> On Mon, Feb 11, 2013 at 08:05:25PM +0000, Anatoly Mikhailov wrote:
> 
>> Добрый день,
>> 
>> Обновившись до Nginx 1.3.12 с версии 1.3.5 заметил, что Chrome перестал 
>> брать из своего кэша (304) статику, которую отдаю таким образом:
>> 
>> location ~ ^/(assets|images|javascripts|stylesheets|swfs|system)/ {
>>   gzip_static       on;
>>   expires           max;
>>   add_header        Cache-Control public;
>>   add_header        Last-Modified "";
>>   add_header        ETag "";
>> }
>> 
>> У нас SWF файлы размером более 1 мегабайта, которые подгружались один раз, 
>> после чего браузерный кэш был очень кстати, поэтому мы отключали все лишние 
>> заголовки.
>> Под Firefox 18 закэшированная статика по-прежнему отдается из браузерного 
>> кэша.
>> Не уверен, но возможно что-то связано с обновлением SPDY.
> 
> У вас отключены оба возможных cache validator'а (Last-Modified, 
> ETag), так что 304 с таким конфигом невозможно получить в 
> принципе.  Chrome штатно пишет "(from cache)" вместо размера, если 
> таки берёт ответ из кеша, именно туда и надо смотреть (ну или в 
> логи nginx'а, чтобы уж совсем наверняка).
> 
> Погонял немного Chrome с подобным конфигом со spdy и просто по 
> https - не вижу каких-либо проблем, равно как и существенных 
> отличий в том, какие ответы берутся из кеша.  Отличия есть между 
> http и https, но это выглядит как отличие в поведении браузера в 
> зависимости от протокола (и как бы намекает, что не надо 
> использовать https, даже со spdy, если хватает http).
> 
> Что до отключения "лишних заголовков" как о мере оптимизации - то 
> это выглядит как странное заблуждение.  Заголовки позволяют 
> браузеру проверить, что ресурс на сервере совпадает с тем, что у 
> него в кеше, и соответственно ответ из кеша можно использовать.  
> Без Last-Modified/ETag - браузеру в аналогичных ситуациях придётся 
> просто загружать ответ заново, целиком.
> 
> -- 
> Maxim Dounin
> http://nginx.com/support.html
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru@xxxxxxxxx
> http://mailman.nginx.org/mailman/listinfo/nginx-ru

Мы отключили 2 из 3х возможных валидатора кэша, так как Conditional Get 
применяется в основном для динамического контента (Cache-Control отключен), там 
связка ETag+LastModified (плюс реверс-прокси) - это очень хорошее и надежное 
решение для разгрузки сервера. Используя эти заголовки, в одном случае контент 
отдается сервером, а клиент берет из 304, в другом - реверс-прокси отдает 
одинаковый ответ из своего кэша при нескольких запросах к серверу, не обращаясь 
к нему непосредственно. Манипуляция этими заголовками на сервере дает большую 
свободу для кэширования. Но все это, разумеется, с отключенным Cache-Control. 
Статика же, наоборот, постоянный статичный контент.

В данном случае речь идет о третьем возможном валидаторе - статике с 
Cache-Control public, который смотрит на имя файла и отдает его из кэша с 304, 
если такой был уже загружен.  Убрав заголовки для статики, мы попытались 
облегчить браузеру необходимость проверки на Conditional Get и генерации md5 
(Etag) каждый раз для статичных файлов. В том вслучае если статика изменяется 
при деплое мы переименовываем файлы по принципу all.js?timestamp

Поправьте, если я что-то не понимаю.

Anatoly
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru