server_name bug

[Борис Долгов]

Тут проблема не в nginx'e, пишите в списки рассылки ядрер linux, freebsd
чтобы меняли логику сокетов - если прослушивается 0.0.0.0 и 1.2.3.4, все
запросы пришедшие на 1.2.3.4 все равно направлять на 0.0.0.0.

30 октября 2008 г. 14:51 пользователь MZ <zuborg at advancedhosters.com>написал:

> В чт, 30/10/2008 в 15:19 +0200, Alex Vorona пишет:
> > 22.10.2008 16:06, MZ wrote:
> > > В ср, 22/10/2008 в 16:25 +0400, Igor Sysoev пишет:
> > >> Проблема в том, что две нижеприведённые конфигурации должны работать
> > >> одинаково:
> > >>
> > >>  server {
> > >>    listen *:80;
> > >>    server_name example.org;
> > >>  }
> > >>  server {
> > >>    listen 1.2.3.4:80;
> > >>    server_name default;
> > >>  }
> > >>
> > >>
> > >>  server {
> > >>    listen *:80 default rcvbuf=16k;
> > >>    server_name example.org;
> > >>  }
> > >>  server {
> > >>    listen 1.2.3.4:80 default rcvbuf=8k;
> > >>    server_name default;
> > >>  }
> > >>
> > >> И они сейчас работают одинаково, несмотря на то, что в первом случае
> > >> используется один сокет, а во втором - два.
> > >
> > > Это не проблема, в обоих конфигурациях меняются только параметры
> > > слушающих сокетов, а конфигурация виртхостов сохраняется идентичной и
> > > таковой, что http-запрос с Host: example.org соответствует первому
> > > виртхосту а не второму.
> >
> > во втором случае http-запрос на IP 1.2.3.4 с Host: example.org попадёт в
> сокет 1.2.3.4:80 с его
> > rcvbuf=8k. Как в этом случае отработать этот запрос в первом виртхосте с
> его сокетом с rcvbuf=16k?
>
> Ах, какое горе. Придется обрабатывать с rcvbug=8k, таки да.
> И, собственно, что с того ? Вы действительно считаете, что правильней
> будет игнорировать первый виртхост и направить запрос во второй, раз уж
> размеры буферов не совпадают ? А если будут совпадать ?
>



-- 
С уважением, Борис Долгов.
icq 77556665
e-mail boris at dolgov.name
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20081030/5633992f/attachment.html>