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 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@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|