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 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
|