nginx 1.3.12 SPDY add_headers bug

[Maxim Dounin]

Hello!

On Tue, Feb 12, 2013 at 08:42:06AM +0000, Anatoly Mikhailov wrote:

[...]

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

Давайте начнём с базовых понятий.  Когда у нас есть ответ из кеша, 
то прежде чем его использовать, нужно

1) Убедиться, что ответ свежий (fresh, not expired), и если да - 
то ответ можно использовать (замечу - 304 тут ни при чём, см. 
ниже).  На этот этап, в частности, можно влиять с помощью 
заголовков Expires и Cache-Control max-age.  (Но вообще следует 
иметь ввиду, что на этом этапе браузеры используют довольно много 
эвристики, и заставить их считать ответ свежим - в общем случае 
невозможно.)

Подробнее тут:
http://tools.ietf.org/html/rfc2616#section-13.2

2) Если ответ не свежий, то проверить его (валидировать) с помощью 
запроса к серверу.  В этом месте используются cache validator'ы, 
которых в HTTP определено два, Last-Modified и ETag.  Тут и только 
тут может появится 304-й ответ (если ресурс на сервере не менялся, 
и cache validator совпадает).

Подробнее тут:
http://tools.ietf.org/html/rfc2616#section-13.3

Использование Cache-Control public - вообще говоря на 
вышеописанные механизмы никак не должен влиять.  Это специальный  
параметр, позволяющий сказать кешам по дороге, что данный 
конкретный ответ - годен для всех пользователей, даже если для 
доступа к ресурсу использовалась авторизация.  (Я допускаю, что 
некоторые браузеры могут учитывать его при определении свежести 
ответа, но это лишь детали эвристики.)

Подробнее про Cache-Control public тут:
http://tools.ietf.org/html/rfc2616#section-14.9.1

Конфиг, который у вас написан, исключает использование механизма 
из пункта (2), и оставляет браузер перед выбором в пункте (1) - 
счесть ответ свежим, или идти на сервер за новым ответом.  AFAIK, 
упомянутые механизмы в браузерах никак не связаны, и запрет 
использования механизма ревалидации - только ухудшает 
ситуацию, никак не влияя на принятие решения о свежести.

-- 
Maxim Dounin
http://nginx.com/support.html