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
Igor Sysoev пишет:
> On Thu, Oct 23, 2008 at 01:13:01PM +1100, Konstantin G. wrote:
>
>> 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' можно совсем убирать из конфига :)
>
> Ну и добавьте этот сервер:
>
> server {
> listen 1.2.3.10:80;
> server_name yet.one.host;
> }
>
> и не нужно ничего вносить в сервер с "*:80".
Тогда может вообще запретить конструкцию "*:80"? Будет хотя бы
всё логично с самого начала.
> Но речь идёт не о об этом, речь идёт о том, что в конфигурацию добавили
> сервер на 1.2.3.10:80:
>
> server {
> listen *:80;
> server_name some.old.host;
> }
>
> server {
> listen 1.2.3.10:80;
> server_name yet.one.host;
> }
>
> и запросы для some.old.host на адрес 1.2.3.10:80 перестали обрабатываться.
Вот именно в этом всё дело. Сначала запросы работали, а потом
вдруг перестали из-за добавления нового сервера где-то в другом
конце конфига. Не слишком ли кардинальные изменения нового хоста
(yet.one.host) на работу уже давно работающих хостов вроде
(some.old.host)?
> Если это всё же нужно, то решается простым добавлением:
Я могу и забыть, что у меня там где-то сервер описан через '*'. А
в результате он не будет работать до тех пор, пока мне об этом не
сообщат?
> server {
> listen *:80;
> listen 1.2.3.10:80;
> server_name some.old.host;
> }
Я всё это понимаю, просто мне кажется такое поведение неудобным,
нелогичным (не интуитивным) и лишённым всякого смысла. Ведь
wildcard * - означает 'всё, что есть', а потом вдруг оказывается
что это не совсем так, и вот такие-то адреса надо ещё
дополнительно описать, т.к. они уже описаны явно где-то в другом
месте.
Это вроде как придумать шелл, в котором для удаления всех файлов
из папки будет не достаточно написать 'rm ./*', а надо будет ещё
отдельно написать 'rm ./*.doc' и 'rm ./*.txt'.
|