ПРОЕКТЫ 


  АРХИВ 


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: server_name bug



On Mon, Nov 03, 2008 at 08:00:09PM +0200, MZ wrote:

> В пн, 03/11/2008 в 20:18 +0300, 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  ... "";
> >    }
> > 
> > Если у меня есть сайт с выделенным адресом - зачем мне гонять для него
> > хэши и регулярные выражения ?
> 
> Вышеуказанная проверка нужна только при наличии обоих типов виртхостов
> (* и specific) только для запросов которые пришли на specific-IP.
> Согласен, что это никак не прибавляет скорости, но на нагруженных
> проектах, где все конфигурируется один раз и надолго, - гораздо проще
> настроить все без использования *-виртхостов вообще, избегая ненужных
> проверок.

*:80 - это не только возможность не описывать все существующие адреса.
Это ещё и возможность описать несуществующие адреса.

> Никто лишний раз гонять хеши и регекспы и не предлагает. Просто иногда
> это бывает вовсе нелишним :)

Ну так при наличии *:80 придётся гонять.


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



 




Copyright © Lexa Software, 1996-2009.