ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proxy_cache_key и fastcgi_cache_key



On 10.01.2014 19:57, Валентин Бартенев wrote:

Смысл значения по умолчанию для proxy_cache_key состоит в том, что
идентифицируется тот ресурс, куда осуществялется проксирование.

Тем самым, если в разных виртуальных серверах проксирование
осуществляется в одно и то же место - будет использован
один и тот же элемент кеша.

Ситуация, когда все размещенные на одном сервере виртуальные хосты
имеют 100% идентичный контент и разные домены практически невозможна.
Такая настройка nginx сейчас может появиться только в результате ошибки.

Еще дефолтовая настройка nginx на $proxy_host может быть полезной
тем, кто "грабит корованы", то есть показыват на своем сайте контент,
который был получен с других сайтов путем проксирования с кешированием.

Например, это может быть отдельный location под общие элементы
и/или ssi-инклуды.  Именно под такие задачи оно исходно и
программировалось, и именно потому и стоят такие значения по
умолчанию - запрашиваем с бекенда то, что указано в proxy_pass, и
кешируем то, что запрашивали.

Просто следует понимать, что задач - больше одной.  И хорошее
решение для одной задачи - может оказаться плохим для другой.

Да, теперь понятно, спасибо. Но всеравно, дефолтовое значение
директивы proxy_cache_key очень странное, такой ключ применим
возможно в 0.0001% конфигураций nginx в мире, а тут - default

Проблема, на самом деле, в том, что прописанное в конфиге
"proxy_set_header Host $host" существенно меняет суть запроса к
бекенду, а значение по умолчанию proxy_cache_key об этом изменении
не знает, его надо обучать этому вручную.  Возможно, именно с этой
стороны и следует подойти к этому вопросу.

Да, очень странное значение proxy_cache_key по умолчанию
и не менее странный пример настройки fastcgi_cache_key,
который приведен в документации. Были ведь такие случаи,
и подозреваю, что неоднократно, когда люди копируют себе
в конфиг fastcgi_cache_key, а потом они в шоке от того,
что происходит с их сайтами и рейтингами в поисковиках.

Лично мне нравится идея привести значение proxy_cache_key по умолчанию
к таковому fastcgi_cache_key, т.е. отсутствует и требуется задавать явно.

ИМХО это полезно, как с точки зрения понятности конфига, так и с точки
зрения унификации между различными upstream-модулями.

А также избавляет нас от странной формулировки в документации:

   "By default, the directive?s value is close to the string"

и упрощает код в нескольких местах.

Мне тоже нравится, только пожалуйста актуализируйте документацию
на сайте по этим директивам proxy_cache_key и fastcgi_cache_key,
чтобы внимательно прочитав ее, можно было понять что туда писать.

Понятно, что такое изменение нарушает совместимость конфигурации и
потребует явного вмешательства при обновлении.  Но если что-то менять
в этом отношении, то я за такой вариант.

Разве много ли таких конфигураций, которые полагались
на дефолтовое значение директивы proxy_cache_key ?

По крайней мере, можно добавить deprecation warning,
если proxy_cache_key явно не задан, а через некоторое
время - менять дефолт, и это почти никого не затронет.

--
Best regards,
 Gena

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


 




Copyright © Lexa Software, 1996-2009.