Re: server_name bug

[Gena Makhomed <gmm@xxxxxxxxx>]

On Friday, October 24, 2008 at 19:47:56, Konstantin G. wrote:

>> MD>>>> Если в системе есть listen сокет для INADDR_ANY,
>> MD>>>> и дополнительно слушающий сокет на каком-либо IP на том же порту -
>> MD>>>> то соединение на этот IP в сокет для INADDR_ANY просто не попадёт.

>> k> А в пределах одной программы может быть
>> k> лучше исходить из удобства для админа?

>> удобно - это когда listen работает по аналогии с server_name
>> сначала ищется точное соответстве, а если его нет, тогда в *

KG> Чем удобно? Тем, что заставляет админа совершать
KG> лишние телодвижения для обхода такого поведения?

я уже писал об этом: виртуальные сервера бывают не только name-based,
но и ip-based. то поведение nginx что есть сейчас - позволяет реализовать
с помощью одного nginx любые комбинации этих двух типов виртуальных серверов,
причем без ввода в конфиг дополнительных директив, вида NameVirtualHost
и без ограничения возможностей, как это сейчас можно наблюдать в Apache.

KG> А какую-то реальную практическую пользу привести можете?
KG> Хоть что-то в качестве примера? Ну или хотя бы пример,
KG> в котором отсутствие таких искусственных ограничений
KG> может помешать нормальной работе сервера,
KG> или усложнит задачу для админа...

например, если в какой-то организации сделан split dns,
и сайты организации (по одному и тому же имени сайта)
должен по разному выглядеть для внешних и для внутренних
клиентов, - это можно реализовать на nginx и нельзя на apache.

>> k> Ведь для удобства конечного пользователя
>> k> программы обычно и пишутся...

>> такие же аргументы были и при создании windows, результат: виста

KG> Это уже передёргивание.

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

вот к чему приводит в результате чрезмерная забота
об удобстве так называемого конечного пользователя.

-- 
Best regards,
 Gena