Re: proxy_cache_key и fastcgi_cache_key

[Gena Makhomed <gmm@xxxxxxxxx>]

On 09.01.2014 16:33, Maxim Dounin wrote:

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

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

Остальным же 99.999% пользователей nginx будет удобно, если дефолтовым
значением сделать proxy_set_header Host $host; ибо с другими вариантами
настройки nginx просто не будет нормально работать с virtual хостами.

Насколько я понимаю суть и смысл default значения настройки -
это значение следует выбирать таким, чтобы оно было удобным
максимально большему числу пользователей nginx. Нет разве ?

По крайней мере, раньше дефолтовым значением server_name
было $hostname; вплоть до версии 0.8.48, а сейчас уже "".
Смысла оставлять дефолт $proxy_host после этого почти нет.

> > возможно имеет смысл дефолтовые настройки сделать такими,
> > чтобы они были безопасными по-умолчанию для всех пользователей?
> > т.е. $host вместо $proxy_host ?
> В запросах на бекенд по умолчанию в заголовке Host
> передаётся именно $proxy_host, и значение proxy_cache_key
> соответсвует тому, что происходит по умолчанию.
> Т.е. по умолчанию - всё безопасно.
Если поменять одну настройку и забыть поменять другую,
тогда все ломается и перестает нормально работать.

Для протокола FastCGI пример из документации сейчас
является "broken by default", потому что в переменной
HTTP_HOST на бекенд уходит значение $http_host из запроса,
а в fastcgi_cache_key рекомендуется localhost:9000$request_uri;

Два варианта:

1. По дефолту стоит $proxy_host и рекомендуется localhost:9000
В худшем случае - контент с разных сайтов перемешивается в выдаче,
пользователи сайтов в шоке, администраторы nginx, которые включили кеш - 
тоже. В результате портится рейтинг сайтов в выдаче поисковых систем.
И как результат этого - портится рейтинг nginx среди пользователей.
Разве надо это кому-то?

2. По дефолту $scheme$host$request_uri; - В худшем случае,
если пользователь криво настроил nginx, так что один и тот же
контент отображается на разных доменных именах, например, 
www.example.com и example.com - будет просто не оптимальная
настройка nginx, когда будет использоваться в два раза больше
диска/памяти для дублирования ключей/значений кеша nginx,
без каких-либо деструктивных последствий для сайтов и пользователей.

Сейчас - по дефолту выбран и рекомендуется в примерах вариант 1.

Чтобы сделать nginx "Secure by default" предлагаю реализовать вариант 2.

Почему "нет" ?

> Если же говорить о том, что может быть достугнуто с помощью
> худождественного выпиливания по конфигу без понимания
> происходящего - то вывод "Мы все умрём" никто не отменял.
По-умолчанию у пользователей nginx высокий уровень доверия
к советам и рекомендациям разработчиков nginx, и если вдруг они
(пользователи) не совсем понимают как работает та или иная директива,
то оставляют директиву в дефолтовом значении, или же настраивают так,
как рекомендуется настраивать в примерах из документации nginx.

Если же эти "ловушки" там были разложены специально,
чтобы пользователи в них попадали и "учились" на своих ошибках -
то это совсем не способствует популярности nginx, так делать не надо.

Например, если смотреть January 2014 Web Server Survey,
то видно что доля nginx уменьшилась и в Market share of all sites
и в Market share of active sites, при этом растут Apache и Microsoft.

Доля nginx выросла в Market share of the top million busiest sites,
но там практически всегда тонкая настройка и хорошее понимание того,
как работает nginx, возможно даже коммерческие контракты на поддержку,
они от дефолтовых значений тех или иных директив nginx почти не зависят.

Побочный эффект "опасных" дефолтовых значений директив nginx
еще и в том, что один раз получив глюки в работе nginx используя
дефолтовое/рекомендуемое в примере значение той или иной директивы
- они начинают вручную в конфиге выписывать значения всех директив,
меняя их по своему усмотрению и больше не доверяя дефолтовым значениям.
Я например, уже неоднократно видет такие конфиги в этом списке рассылки.

> > кстати, аналогичный вопрос касается и дефолтового значнеия proxy_set_header
> > - http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_set_header
> >
> > syntax:         proxy_set_header field value;
> > default:        proxy_set_header Host $proxy_host;
> >                  proxy_set_header Connection close;
> >
> > хотя ниже идет рекомендация делать proxy_set_header Host $host;
> > почему бы не сделать $host значением по-умолчанию?
> Ниже говорится о том, что если хочется передать на бекенд значение
> Host'а из запроса, то этом можно сделать с помощью $http_host, но
> лучше - с помощью $host (и объясняется, почему).
У 99.999% пользователей nginx вот именно такое желание и есть,
"передать на бекенд $host в заголовке Host" через proxy/fastcgi.

Сейчас - на backend уходит $proxy_host и $http_host соответственно
вместо желаемого и ожидаемого клиентами значения $host

"Secure by default" - это ведь совсем не сложно.
Тем более, что nginx включили в состав OpenBSD.

--
Best regards,
 Gena

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