Re: server_name bug

[MZ <zuborg@xxxxxxxxxxxxxxxxxxx>]

В ср, 22/10/2008 в 13:52 +0400, Anton Yuzhaninov пишет:
> On 22.10.2008 13:20, MZ wrote:
> > В вт, 21/10/2008 в 22:40 +0400, Igor Sysoev пишет:
> >> On Tue, Oct 21, 2008 at 09:27:40PM +0300, MZ wrote:
> >>
> >>> Обнаружил такой баг
> >>> server {
> >>>   listen *:80;
> >>>   server_name example.org;
> >>> }
> >>> server {
> >>>   listen 1.2.3.4:80;
> >>>   server_name default;
> >>> }
> >>>
> >>> запрос на 1.2.3.4 с Host: example.org попадает не в первый vhost а во
> >>> второй
> >>>
> >>> nginx 0.6.31
> >> Это не баг. Сначала проверяются адрес:порт, а только потом имя.
> >> Поскольку listen 1.2.3.4:80 описан явно, то, с точки зрения nginx'а,
> >> сервер, в котором он описан, является единственным приёмником таких 
> >> запросов.
> > Поскольку присутствует *:80 то приемников для коннектов на 1.2.3.4 уже
> > не одна штука, а включая все виртхосты с 1.2.3.4:80 и все с *:80.
> > 
> >> Особенно хорошо это видно, если поставить
> >>
> >>    listen 1.2.3.4:80 default bind;
> >>
> >> Тогда соединение в принципе не попадёт в *:80. Так устроены сокеты.
> 
> > без bind соединение попадает в *:80, но не обрабатывается первым
> > виртхостом - разве это не баг ?
> > 
> 
> Нет, то как это происходит сейчас, это наиболее логичное поведение.
> 
> Это чем то похоже на more specific route в маршрутизации - если есть
> маршрут на определенный IP, то используется он, а не default route (аналог 
> *:80).
> 
> А чтобы было проще поддерживать конфигурацию старайтесь не смешивать *:80 и 
> явное указание IP,
> и там где нужно явно указывать default.

Если уж сравнивать с specific route - то почему сравнивается 1.2.3.4 с *
(когда запрос приходит на 1.2.3.4) а не "server_name example.org" с
"server_name nonexample.org" когда в запросе присутвует "Host:
example.org" ?

Я считаю логичным ожидать что запрос попадет в какой-то виртхост по
соответствию Host с server_name, коли уж оба listen соответствуют ипу на
который пришел запрос.