server_name bug

[Igor Sysoev]

On Mon, Nov 03, 2008 at 01:18:16PM +0200, MZ wrote:

> В вт, 21/10/2008 в 21:27 +0300, MZ пишет:
> > Обнаружил такой баг
> > 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
> 
> Небольшой итог этой широко развернувшейся дискуссии.
> 
> 1. Никто так и не сумел привести рабочего примера, когда текущее
> поведение nginx позволяет реализовать то, что не позволяет реализовать
> модифицированное поведение.
> 
> 2. Никто так и не сумел привести аргументов, отличных от
>   - "так реализованы сокеты, и listen никаких дополнительных действий не
>     производит и не должен"
>   - "новую опцию вводить некошерно, и текущих уже достаточно чтоб
>     запутаться"
>   - "менять текущее поведение некошерно, так как что-то где-то может
>     поломаться (хотя никто текущее поведение не использует)"
>   - "новая опция/поведение внесет смуту в умы непросвещенных админов"
> 
> 3. спасение рук утопающих - дело рук самих утопающих
> 
> Спасибо за внимание.

Сейчас к адресам привязаны хэши имён (точное совпадение, *., .*)
и списки регулярных выражений. Если адрес есть только в одном сервере,
то хэшей и списка нет - проверять нечего - он и так дефолтный сервер.
В предлагаемой схеме нужно будет сначала проверять хэши и список для
этого адреса, а потом хэши и список для *:80. В противном случае не
будет работать схема с отсутствующим Host (пустым именем):

   server {
       listen       *:80;
       server_name  ... "";
   }

   server {
       listen       1.2.3.4:80;
       server_name  ... "";
   }

Если у меня есть сайт с выделенным адресом - зачем мне гонять для него
хэши и регулярные выражения ?


-- 
Игорь Сысоев
http://sysoev.ru