Re: server_name bug

["Konstantin G." <www-master@xxxxxxxxxx>]

Gena Makhomed пишет:
> 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.

server {
  listen *:80;
  server_name virtual.host;
}
server {
  listen 1.2.3.4:80;
  server_name ipbased.host;
}

Все запросы, пришедшие на 1.2.3.4:80, но не содержащие
"Host: virtual.host" идут на ipbased. Благодаря правильным
записям в DNS - такие запросы и не будут ходить на 1.2.3.4
Если же по какой-то причине нужно, чтобы ipbased обрабатывал и
запросы с "Host: virtual.host" - тогда придется заменить "listen
*:80;" на прямое перечисление адресов.

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

Описываем два сервера с одинаковыми server_name и разными listen.
Если нужный server_name имеется на данном IP, то дальше уже не
смотрим. Так что тут поведение должно остаться без изменений в
моём представлении.

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

Качество кода никак не зависит от наличия/отсутствия удобного
ГУИ. Nginx ведь не станет хуже, если к нему нарисовать удобный
GUI, позволяющий делать основные простейшие настройки? Тем более,
что нарисовать его не сложно.