Re: server_name bug

[Gena Makhomed <gmm@xxxxxxxxx>]

On Wednesday, October 29, 2008 at 2:29:03, Konstantin G. wrote:

>> зачем выдумывать новую директиву, если все отлично работает и без нее?

KG> Я уже устал повторять - чтобы небыло нужды прибегать к хакам типа:

KG> listen *:80;
KG> listen 10.0.0.1:80;
KG> listen 10.0.0.2:80;
KG> listen 10.0.0.3:80;

KG> и т.д. в одном и том же сервере.

несколько "listen" в одном "server" - это не хак.
и даже лучше - явно указывать ip-адреса в listen,
потому что это работает более эффективно чем c *.

>> GUI в IIS - это *пример*, к чему привела *в результате*
>> *чрезмерная* забота об удобстве конечного пользователя.

KG> Ни одного доказательства связи этих
KG> двух вещей так и не предоставлено.

связь простая, - редактировать конфигурацию в IIS неудобно.
хотя все упрощения делались там ради удобства пользователя.

>> вот если бы Вы написали внешний lint для конфига nginx -
>> к Вам бы не было никаких вопросов. так ведь вместо этого
>> Вы требуете, чтобы автор nginx внес изменения в код сервера,
>> согласно Вашим туманным представлениям о том, как это было бы
>> может быть удобно другим пользователям nginx. в этом проблема.

KG> 1. Мои представления не туманны, алгоритм
KG> работы был описан весьма подробно и исчерпывающе.

только вот в результате таких "улучшений" - директива listen *:80
станет бесполезной, потому что она превратится в syntactic sugar.

например, сейчас такая конфигурация будет работать нормально:

server {
    listen *:80;
    server_name external_site;
}

server {
    listen 10.20.30.40:80;
    server_name internal_site1;
}

server {
    listen 10.20.30.40:80;
    server_name internal_site2;
}

после внесения "улучшений" - на внешнем интерфейсе станут доступны
внутренние сайты. если внешний адрес динамический - всё, приехали!
явно указать ip - нельзя, использовать listen *:80; - тоже нельзя.

и даже предлагаемая *новая* директива "ipbased: on;" тут ничем
не поможет, потому что все эти виртуальные хосты - name-based.

-- 
Best regards,
 Gena