ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
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'.



 




Copyright © Lexa Software, 1996-2009.