location /

[Gena Makhomed]

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