server_name bug

[Andrey N. Oktyabrski]

Dmitriy MiksIr wrote:
>>> Почему же?
>>> Если есть два сервера
>>> server_name *.domain.ru
>>> и
>>> server_name old.domain.ru
>>> описанных именно в этом порядке
>>> и запрос приходит на old.domain.ru - в каком сервере логично этот 
>>> запрос отработать?
>> Не надо выдёргивать фразы из контекста. Если есть такие server_name и 
>> запрос приедет на адрес, явно прописанный в listen для *.domain.ru c 
>> Host: old.domain.ru, nginx отправит его в первый server, не глядя на 
>> server_name вообще, если old.domain.ru висит на *:80. То есть, выбор 
>> хоста по адресу (по логике сокетов) сейчас имеет приоритет над выбором 
>> хоста по имени.
> И это логично, ибо сначала происходит tcp соединение, а уже потом - 
> отсылка Host и т.д. и т.п. Просто Вы почему-то считаете, что 
> listen+server_name - это неразрывная пара для определения name-based 
> виртуального сервера (терминами апача). Но это не так - listen отдельно 
> и отвечает за установку tcp соединения (вооще не только http есть в 
> nginx), а уже потом по _выбранному_ сокету приходят Host и выбор сервера 
> по нему. Гляда на такую последовательность действий - все тоже 
> становится очень логично. Логика, она вообще такая штука - зависит с 
> какой стороны посмотреть.
Та ото-ж... И это логично, и то логично. Поэтому я не использую в 
listen'ах и *, и адрес в пределах одного nginx'a, только что-то одно. 
Дабы исключить те грабли, которые привели к этому треду.

Хотя, если честно, мне трудно понять, почему изменить существующее 
поведение дополнительной опцией идеологически невозможно. Ну приняли мы 
соединение на этот сокет, почему не выбрать после этого нужный server из 
бОльшего числа кандидатов? Тем более, если опция по умолчанию выключена.