Re: server_name bug

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

Gena Makhomed пишет:
> On Monday, October 27, 2008 at 18:07:58, Konstantin G. wrote:
> 
> KG>>> Хотя я всё-равно предпочёл бы иметь
> KG>>> дополнительный параметр (ipbased: on).
> KG>>> Это было бы и наглядней, и позволило бы нгинксу отслеживать
> KG>>> ошибки конфигурирования. - Т.е. если админ по ошибке указал
> KG>>> два сервера, слушающих один и тот же адрес:порт,
> KG>>> но хотя бы для одного из них указано "ipbased: on;"
> KG>>> то можно указать ему на ошибку.
> 
> ip-based virtual host`ы сейчас уже используются достаточно редко,
> - они нужны только для клиентов работающих по протоколу HTTP 0.9.
> 
> наличие на одном адрес:порт одновременно ip-based и name-based
> virtual host`ов - ничему не противоречит, зачем это запрещать?

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

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

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

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

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

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


Gena Makhomed пишет:
> On Monday, October 27, 2008 at 18:14:44, Konstantin G. wrote:
>
> KG> Слишком мало примеров для статистики.
>
> ситуация будет такой же, если сделать выборку
> и по всем веб-серверам существующим в природе.

Сделайте. Тогда уже и можно будет говорить предметно. И не
останавливайтесь только на веб-серверах или вообще на серверах,
раз уж речь идёт GUI vs NOT GUI

А я пока начну: xchat, kopete, opera, the bat, licq, OpenOffice,
amarok - кажется эти продукты не славятся большими проблемами с
безопасностью? И это только то, что сразу пришло в голову.
В то же время, отсутствие ГУИ тоже особо не помогает: в apache
тоже периодически находят уязвимости, и даже links этого не
избежал. А в lighttpd и в bind это даже происходит довольно часто.

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

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

>>> даже в Microsoft поняли тупиковость своего подхода
>>> и в Server 2008 уже появилась возможность запускать
>>> сервера в text-mode, без GUI`евого инерфейса.
>
> KG> И что, в их продуктах сразу стало меньше уязвимостей?
>
> по крайней мере, это одна из целей, которую
> они пытаются достичь созданием Server Core.

Пытаться они могут всё что угодно. Ещё со времён трастинг
компьютинга, если не раньше, пытаются. Вот когда чего-то
добьются, тогда уже и можно будет что-то говорить. ИМХО это всё
вообще у них только пиар и маркетинг.