nginx 1.3.12 SPDY add_headers bug

[Anatoly Mikhailov]

On Feb 12, 2013, at 3:56 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
> 
> On Tue, Feb 12, 2013 at 02:55:54PM +0000, Anatoly Mikhailov wrote:
> 
> [...]
> 
>> Эмпирическим путем мы выяснили, что 'Cache-Control public' все браузеры воспринимают одинаково
>> и, более того, бонусом кэшируют статику для SSL-соединения, которая, в противном случае, очищается 
>> из браузерного кэша (и на промежуточных прокси) без данного заголовка.
>> Все тестирование, которое мы проводили никак не привело к ухудшению ситуации, все браузеры
>> вели себя, может не по спецификации, но предсказуемо.
> 
> Да, судя по всему как минимум в FF до недавнего времени это было 
> нужно для кеширования ответов по https:
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=531801
> 
>> Сейчас включил логи и протестировал с Last-Modified/E-Tag и без них. В данном конкретном случае
>> это не повлияло на результат. Сейчас более подробно.
>> 
>> У нас стейджинг сервер с самоподписанным SSL сертификатом, на нем Nginx 1.3.12 + SPDY.
>> На продакшне, разумеется, валидный SSL сертификат с Nginx 1.3.5 + SPDY 50, если не ошибаюсь.
>> На продакшн серверах вся статика кэшируется в браузерах и на сервер запросы не идут.
>> 
>> На стейджинге Firefox все берет из своего кэша, не обращаясь на сервер (наличие E-Tags/Last-Modified не влияет),
>> но Chrome на стейджинге постоянно идет на сервер за статикой, тут не влияет наличие этих заголовков.
>> Вопрос - может ли невалидный сертификат повлиять на это? 
> 
> Провёл простой эксперимент - да, невалидный сертификат влияет, по 
> крайней мере в случае Chrome'а.

Максим, спасибо огромное! пошел обновлять бинарник nginx на продакшне.

> 
> -- 
> Maxim Dounin
> http://nginx.com/support.html
> 
> _______________________________________________
> nginx-ru mailing list
> nginx-ru at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru


Анатолий