server_name bug

[Gena Makhomed]

On Tuesday, October 28, 2008 at 3:27:27, Konstantin G. wrote:

KG>>>>> Хотя я всё-равно предпочёл бы иметь дополнительный параметр
KG>>>>> (ipbased: on). Это было бы и наглядней, и позволило бы нгинксу
KG>>>>> отслеживать ошибки конфигурирования. - Т.е. если админ по ошибке
KG>>>>> указал два сервера, слушающих один и тот же адрес:порт,
KG>>>>> но хотя бы для одного из них указано "ipbased: on;"
KG>>>>> то можно указать ему на ошибку.

>> ip-based virtual host`ы сейчас уже используются достаточно редко,
>> - они нужны только для клиентов работающих по протоколу HTTP 0.9.

>> наличие на одном адрес:порт одновременно ip-based и name-based
>> virtual host`ов - ничему не противоречит, зачем это запрещать?

KG> Я никогда не предлагал ничего запрещать. Без параметра
KG> "ipbased: on;" всё должно было бы работать как и раньше,
KG> даже немножко проще.

KG> Например:

KG> server {
KG>   listen *:80;
KG>   server_name virtual-all.host;
KG> }
KG> server {
KG>   listen 10.0.0.1:80;
KG>   server_name ipbased1.host;
KG>   ipbased: on;
KG> }
KG> server {
KG>   listen 10.0.0.2:80 default;
KG>   server_name ipbased2.host;
KG> }
KG> server {
KG>   listen 10.0.0.2:80;
KG>   server_name virtual2.host;
KG> }

KG> Здесь:
KG> - все запросы на 10.0.0.2 с "Host: virtual2.host" должны попадать
KG> на последний сервер (virtual2.host).
KG> - все запросы на 10.0.0.2 (и любой другой кроме 10.0.0.1) с
KG> "Host: virtual-all.host" должны попадать на первый сервер
KG> (virtual-all.host). В текущем поведении nginx они на него не
KG> попадают через 10.0.0.2 (чтобы попадали, надо дополнительно
KG> описать в этом сервере "listen 10.0.0.2:80;", что мне и кажется
KG> неудобным).
KG> - все остальные запросы на 10.0.0.2 (с любым "Host:" или вообще
KG> без него) - на ipbased2.host
KG> - а вот всё, что приходит на 10.0.0.1 должно попадать только на
KG> него, независимо от заголовка "Host:" (даже если такой Host
KG> описан где-то на другом сервере). Да, знаю, это очень-очень редко
KG> в действительности может понадобиться, но всё-таки.

KG> Если я что-то непонятно объяснил, то спрашивайте. Если всё
KG> понятно, то объясните - что вам не нравится в таком поведении?

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

«не следует умножать сущности без необходимости».

>> конфиг имеет С-like синтаксис. если начинать вводить искусственные
>> ограничения, - он из C-like в результате превратится в Pascal-like.

KG> Снова не понял. Как связаны какие-либо ограничения и синтаксис?

разные парадигмы / подходы имеют свое отражение в синтаксисе.

KG> В то же время, отсутствие ГУИ тоже особо не помогает: в apache
KG> тоже периодически находят уязвимости, и даже links этого не
KG> избежал. А в lighttpd и в bind это даже происходит довольно часто.

IIS - это *пример*, к чему иногда приводит подход "Ведь для
удобства конечного пользователя программы обычно и пишутся..."

>> для любого использования будет полезнее стабильная работа,
>> чем различные GUI`шные редакторы конфигурации веб-сервера.

KG> С этим никто не спорит, только вы пока ещё
KG> не доказали взаимосвязанность этих двух вещей.

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

KG> А вот если кто-то возьмёт и напишет ГУИ оболочку,
KG> которая будет парсить (читать и писать) конфиг нгинкса,
KG> то что - код самого нгинкса сразу станет плохим от этого, да?

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

а внешний lint для конфига Вы можете написать прямо сейчас.

только вместо

ipbased on;

в конфиге надо будет писать

#ipbased on;

весь функционал по дополнительной проверке синтаксиса
конфига - можно сделать с помощью сторонней программы.

-- 
Best regards,
 Gena