server_name bug

Konstantin G. www-master at arsvest.ru
Thu Oct 23 06:13:01 MSD 2008


Igor Sysoev пишет:
> On Thu, Oct 23, 2008 at 01:57:37AM +1100, Konstantin G. wrote:
> 
>> Igor Sysoev пишет:
>>> On Wed, Oct 22, 2008 at 02:14:36PM +0300, MZ wrote:
>>>
>>>> Я считаю логичным ожидать что запрос попадет в какой-то виртхост по
>>>> соответствию Host с server_name, коли уж оба listen соответствуют ипу на
>>>> который пришел запрос.
>>> А как быть с ситуацией, когда запросы начинают обрабатываться по-другому
>>> после добавления в listen параметров ?
>> Выдавать WARNING в консоль при тестировании конфигурации
>> и в лог при запуске - о том, что обращения к такому-то
>> серверу через такой-то IP будут обрабатываться другим сокетом?
> 
> А смысл ? Текущая реализация позволяет явно указать, на каких адресах
> слушает сервер. Если нужно добавить специфичный адрес в сервер с *:80,
> то это легко делается listen:
> 
>   server {
>      listen *:80;
>      listen 1.2.3.4:80;
>      listen 1.2.3.5:80;

Ну тогда варнинг о том, что несмотря на 'listen *:80' обращения
на определённый IP обрабатываться вообще не будут, и предложить
воркэрраунд :)
Но если я правильно понимаю, то в этом случае обработка всё-равно
будет вестись другим сокетом с другими параметрами. Т.е. какой
смысл так усложнять конфиг?

И вообще, IMHO, у многих будут возникать ситуации, когда
множество серверов уже описаны как *:80 и вдруг возникает
необходимость добавить новый сервер на одном определенном IP.
И тогда возникает необходимость вносить изменения во все уже
работающие серверы (или предлагается делать инклуды даже в этом
случае?) А потом ещё один - на другом IP. В результате 'listen
*:80' можно совсем убирать из конфига :)

Между тем, как я понял, вы пытаетесь сделать конфиг нгикса таким,
чтобы внесение изменений в одном месте ничего не ломало в
другом... И в то же время, я полагаю, большинству администраторов
никогда не понадобится настраивать разные параметры сокетов на
разных IP-адресах. Т.е. в идеале большинство админов с такими
заморочками даже не столкнётся.





More information about the nginx-ru mailing list