On Friday 10 January 2014 23:10:17 Gena Makhomed wrote:
> On 10.01.2014 22:48, Валентин Бартенев wrote:
>
> >> Разве много ли таких конфигураций, которые полагались
> >> на дефолтовое значение директивы proxy_cache_key ?
>
> > Полагаю не мало людей используют кэш для одного хоста
> > и ключ по умолчанию у них нормально работает, а после
> > изменения перестанет.
>
> Ok, но ведь при парсинге конфига nginx может посчитать

Это не так просто и ведет к довольно сильному layering violation.

Следует учесть, что в nginx:

1. Директивы из разных модулей обычно ничего не знают о существовании
друг-друга, а равно и значениях;

2. Могут встречаться в конфиге в произвольном порядке, а директива
server_name вообще несколько раз. Такая конфигурация валидна:

server {
server_name example.org;

location {
proxy_pass backend;
}

server_name example.org;
}

3. Директива proxy_cache_key может быть задана также на уровнях http, server,
и location-ах любой степени вложенности.

4. Как отсутствие, так и наличие директивы proxy_cache_key, не означает,
что кэш вообще включен и используется. Для этого должно совпасть ещё
минимум два условия:

а) Наличие директивы proxy_pass в данном location-не, или на
уровне server (неявный location-ой);

б) Наличие директивы proxy_cache со значением отличным от off
в этом же location, или унаследование такового с уровня выше.


> количество хостов в конфиге, и если там всего один хост
> и явно не задан в конфиге proxy_cache_key - выдавать warning
> но продолжать работать со старым дефолтовым значением,
> а если хостов больше одного - то переключать на новый
> дефолт и выдавать fatal error,

Типичный конфиг:

server_name example.com www.example.com;


> если proxy_cache_key
> не определен - всеравно в такой конфигурации от
> proxy_cache_key $scheme$proxy_host$request_uri;
> будет больше вреда, чем пользы из-за перемешивания
> в кеше контента от разных virtual host`ов.
>
> А если это highload, и это был отдельный location
> под общие элементы и/или ssi-инклуды -
> его админы в любом случае внимательно
> читают CHANGES и все варнинги от nginx.
>
> В таком варианте ведь ничего не сломается?

Почему ни warning, ни error сделать не представляется разумным - пояснил в
самом начале.

Опять же, ИМХО если что-то предпринимать в этом отношении, то лучше поступить
следующим образом:

1. Добавить второй параметр, задающий ключ, в директивы proxy_cache,
fastcgi_cache, scgi_cache, uwsgi_cache;

2. Отказаться от отдельных директив *_cache_key.

Причем возможно сделать с промежуточным этапом: параметр опционален и warning
при его отсутствии или наличии *_cache_key директив в конфиге.

Либо разом: второй параметр обязателен когда значение первого отлично от off,
и соответствующие ошибки - не запускаемся пока не поправят конфиг.

Очевидные плюсы:

1. Упрощается конфигурация, поскольку ИМХО от раздельного задания ключа и
зоны никакой практической пользы, зато какое-то сложное условие включения
кэша в location-е.

2. Изменения потребуют явного вмешательства и принятия мер со стороны
администратора, а не пройдут незамеченными в виде тихо переставшего
работать кэша.

И очевидный минус: затронет всех, кто использует кэш.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru