server_name bug

[Maxim Dounin]

Hello!

On Wed, Oct 22, 2008 at 12:20:37PM +0300, 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 сокет для INADDR_ANY, и 
дополнительно слушающий сокет на каком-либо IP на том же порту - 
то соединение на этот IP в сокет для INADDR_ANY просто не попадёт.

То, что nginx по умолчанию при такой конфигурации открывает только 
один listen сокет - это внутренняя оптимизация, не более того.  
Поведение от наличия/отсутствия оптимизаций меняться не должно.

> 
> > Особенно хорошо это видно, если поставить
> > 
> >    listen 1.2.3.4:80 default bind;
> > 
> > Тогда соединение в принципе не попадёт в *:80. Так устроены сокеты.
> без bind соединение попадает в *:80, но не обрабатывается первым
> виртхостом - разве это не баг ?

Нет, см. выше.  То, что оно попадает (где-то внутри) в сокет, 
слушающий на *, никоим образом не должно менять поведение.

Hint: bind - не единственный параметр, который приводит к 
отключению оптимизации и открытию отдельного listen сокета для 
данного ip.

Maxim Dounin