nginx 1.3.12 SPDY add_headers bug
Anatoly Mikhailov
anatoly at sonru.com
Tue Feb 12 08:42:06 UTC 2013
On 12.02.2013, at 1:49, Maxim Dounin <mdounin at mdounin.ru> 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 at nginx.org
> 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