Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: location /
On 09.10.2011 23:18, Maxim Dounin wrote:
Вопрос исключительно в том, хочется ли тому, кто пишет
конфиг, разбираться в том, как именно поймёт nginx написанное.
это необходимое условие для того, чтобы nginx
на веб-сервере работал предсказуемым образом.
потому что если тот кто пишет конфиг, станет понимать его одним
способом, а nginx другим - то ничего хорошего из этого не будет.
server {
rewrite ^(.*) /prefix$1;
}
происходит зацикливание rewrite or internal redirection
cycle while processing "/prefix/prefix/prefix/prefix/prefix/prefix/..."
И причина, в общем-то, очевидна - если знать нюансы. В первом
конфиге на самом деле написано нечто вроде:
server {
rewrite ^(.*) /prefix$1;
location / {
rewrite ^(.*) /prefix$1;
}
}
И по понятным причинам будет цикл.
т.е. если в конфиге явно не указан location / { ... }
nginx просто самостоятельно сделает неявный location / { ... }
поместив в него все директивы, которые есь внутри server { ... }
и которые могут находиться внутри директивы location / { ... } ?
и насколько я понимаю, это единственное недокументированное
поведение, если в конфиге явно не будет указан location / ?
кстати, а почему нельзя в случае отсутствия location /
сделать пустой location / {} в который будут наследоваться
необходимые директивы с верхних уровней, например, root и т.п.
тогда например, глюка с зацикливанием rewrite не будет...
(и вообще никаких глюков и "сюрпризов" тогда не будет, AFAIU)
я раньше предполагал что в таком случае создается пустой location / {}
по крайней мере, это было бы ожидаемым поведением, - "без сюрпризов".
("the principle of least surprise", как в языках программирования)
...
так же как желательно будет делать и server-по-умолчанию, куда будут
попадать все запросы, для которых нет более специфичного server`а.
Сервер по умолчанию - всегда есть, это первый описанный сервер на
данном сокете. Если используется debian и производные с их
"include *" - то да, имеет смысл описать его явно.
не только Debian. например, на сайте http://nginx.org/packages/
лежат пакеты для RHEL и CentOS, в конфиге которых также написано
include /etc/nginx/conf.d/*.conf;
это было сделано, насколько я понимаю, по аналогии с apache,
потому что в дефолтовом конфиге апача в CentOS также указано
Include conf.d/*.conf
но тут есть и одно очень существенное отличие,
о котором говорится в /etc/httpd/conf.d/README
"Files are processed in alphabetical order",
в случае же nginx - ни в документации,
ни в conf.d/README, ни в исходниках
не написано, что включаемые файлы
обрабатываются in alphabetical order.
GLOB_NOSORT в исходниках nginx стоит ради производительности,
потому что через include включаться могут и сотни тысяч файлов.
поэтому - явно указывать default_server в конфигах необходимо всегда,
тем более, что в дефолтовом server`е обычно всегда стоит "return 444"
$ cat /etc/nginx/conf.d/default-server
#
# default-server
#
server {
listen 11.11.11.11:80 default_server backlog=1024;
listen 22.22.22.22:80 default_server backlog=1024;
listen 33.33.33.33:80 default_server backlog=1024;
listen 44.44.44.44:80 default_server backlog=1024;
return 444;
}
то, что для nginx "Сервер по умолчанию - всегда есть" - это понятно.
так же как и location по умолчанию == 'location /' тоже всегда есть.
но вот "Сервер по умолчанию" с точки зрения nginx может оказаться
совсем не таким, как его себе представляет тот, кто пишет конфиг.
P.S.
насколько я понимаю, сейчас практически во всех дистрибутивах
уже применяется технология "include /etc/nginx/conf.d/*.conf;"
чтобы можно было сделать "1 virtual host == 1 configuration file".
и можно было бы легко disab`лить virtual host`ы, просто переименовывая
конфиг или перемещая его в другой каталог, например, в ./sites-disabled
--
Best regards,
Gena
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru
|
