ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
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


 




Copyright © Lexa Software, 1996-2009.