server_name bug
Konstantin G.
www-master at arsvest.ru
Mon Oct 27 02:46:54 MSK 2008
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, позволяющий делать основные простейшие настройки? Тем более,
что нарисовать его не сложно.
More information about the nginx-ru
mailing list