On 09.01.2014 14:10, Maxim Dounin wrote:

>> второй вопрос - по поводу дефолтовых значений
>> proxy_cache_key и fastcgi_cache_key, они почему-то разные.
>>
>> syntax: fastcgi_cache_key string;
>> default: —
>>
>> syntax: proxy_cache_key string;
>> default: proxy_cache_key $scheme$proxy_host$request_uri;

...

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

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

так ведь именно в этом и состоит суть проблемы. в разных виртуальных
серверах проксирование обычно осуществляется на один и тот же
backend/upstream, и для *разных* виртуальных серверов будет
использован один и тот же элемент кеша $scheme$XXX$request_uri.

при proxy_pass http://127.0.0.1:80/ в $proxy_host окажется 127.0.0.1
аналогично, и в случае fastcgi_cache_key localhost:9000$request_uri;

- запросы к разным virtual host`ам будут попадать в один и тот же
элемент кеша, и nginx не будет различать *разные* virtual host`ы.

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

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

===================================================================

кстати, аналогичный вопрос касается и дефолтового значнеия
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 значением по-умолчанию?

в fastcgi_params: fastcgi_param SERVER_NAME $server_name
- разве здесь не будет лучше передавать значение $host ?

если пользователь пишет в конфиге

server_name example.com example.net example.org;
fastcgi_pass ... ;

- на backend придет example.com даже в том случае,
если исходный запрос был к example.org или к example.net

почему бы здесь тоже не передавать $host ?

тогда fastcgi_* и proxy_* будут максимально похожи между собой,
что облегчит пользователям миграцию между разными типами backend`ов.

ведь нигде в спецификации fastcgi не требуется передавать другое
имя хоста в SERVER_NAME, вместо того, на которое пришел исходный запрос.

тем более, что CGI спецификация, на которой основана FastCGI
спецификация писалась еще в то время, когда никаких виртуальных
хостов еше даже в проекте не было. Там имеется ввиду все-таки $host

P.S.

решить проблему дублирования кеша для разных имен www.example.com
и example.com очень просто - выключить кеш на example.com и сделать
редирект на www.example.com - это и с точки зрения SEO полезно будет.

а кому надо дублирование контента на двух разных доменах в интернете
- могут явно прописать www.example.com или $server_name в *_cache_key
вместо дефолтового значения $host.

--
Best regards,
Gena

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