server_name bug

[kot]

Mykola Dzham пишет:
>  MZ (zuborg at advancedhosters.com):
>> В ср, 22/10/2008 в 14:13 +0400, Maxim Dounin пишет:
>>> Hello!
>>>
>>> On Wed, Oct 22, 2008 at 12:20:37PM +0300, MZ wrote:
>>>
>>>> В вт, 21/10/2008 в 22:40 +0400, Igor Sysoev пишет:
>>>>> On Tue, Oct 21, 2008 at 09:27:40PM +0300, MZ wrote:
>>>>>
>>>>>> Обнаружил такой баг
>>>>>> 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
>>>>> Это не баг. Сначала проверяются адрес:порт, а только потом имя.
>>>>> Поскольку listen 1.2.3.4:80 описан явно, то, с точки зрения nginx'а,
>>>>> сервер, в котором он описан, является единственным приёмником таких запросов.
>>>> Поскольку присутствует *:80 то приемников для коннектов на 1.2.3.4 уже
>>>> не одна штука, а включая все виртхосты с 1.2.3.4:80 и все с *:80.
>>> Нет.  Если в системе есть listen сокет для INADDR_ANY, и 
>>> дополнительно слушающий сокет на каком-либо IP на том же порту - 
>>> то соединение на этот IP в сокет для INADDR_ANY просто не попадёт.
>>>
>>> То, что nginx по умолчанию при такой конфигурации открывает только 
>>> один listen сокет - это внутренняя оптимизация, не более того.  
>>> Поведение от наличия/отсутствия оптимизаций меняться не должно.
>> Согласен что это всего лишь оптимизация, но я не считаю адекватным
>> матчинг виртхоста по значению директивы listen в ущерб значению хидера
>> "Host" и директивы server_name.
> 
> А Вам известные адекватные в Вашем понимании http сервера?

Мне не известны, а что это меняет?

> Например apache тоже будет у Вас не адекватным.
> А поведение таки вполне логичное если исходить из принципов работы
> сокетов.

А зачем вообще исходить из этих принципов в пределах одной
программы? Какой в этом смысл?
Вот если бы другая программа открыла ещё один сокет на том же
порту, тогда да, от принципа работы сокетов никуда не деться. А в
пределах одной программы может быть лучше исходить из удобства
для админа? Ведь для удобства конечного пользователя программы
обычно и пишутся...