server_name bug

[Gena Makhomed]

On Thursday, October 30, 2008 at 13:22:31, MZ wrote:

>> M> И лично я не вижу никаких причин почему запрос пришедший
>> M> не в wildcard-сокет должен игнорировать виртхосты с *:80,
>> M> если отвлечься от того, как устроены сокеты.

>> потому что кроме name-based virtual-host`ов есть еще и ip-based.
>> и для них поле заголовка "Host:" - вообще должно игнорироваться.

M> Может Вы не в курсе, но кроме ip-based виртхостов
M> есть ещё и name-based ! В которых поле заголовка
M> Host: не! должно игнорироваться.

server {
  listen *:80;
  server_name site.com;
  server_name *.site.com;
}

server {
  listen 10.20.30.40:80;
  server_name site.com;
  server_name mail.*;
}

если listen *:80; будет включать в себя listen 10.20.30.40:80;
в каком из серверов должен обрабатываться запрос Host: mail.site.com ?
а в каком из них запрос Host: site.com ? а если запрос придет на адрес
10.20.30.40 или на адрес 10.20.30.50 (этот ip попадает в первый listen)

очень хотелось бы узнать ответ для всех 4-х вариантов запроса
( 2 ip x 2 host ) и почему nginx должен вести себя именно так.

похоже что получается более сложная и запутанная схема работы,
по сравнению с теперешним вариантом, когда сначала проверяется
listen, а потом - server_name. потому что сейчас логика понятна.

M> Специально разработали новый HTTP протокол для этого,
M> потому что на одних ip-based виртхостах далеко не уедешь.

>> поскольку явной директивы для разделения виртуальных хостов
>> на ip-based и name-based в nginx нет, остается только listen.

M> Не хотите использовать name-based виртхосты - не пишите
M> в конф директив server_name. Логично ? Логично !

совсем не логично. директива ServerName например присутствует
даже в ip-based виртуалхостах Apache, аналогично это и в nginx.

тут есть такое понятие, как "основное имя сервера", которое может
использоваться, например, для редиректов. (server_name_in_redirect)

>> M> Кто-нибудь сможет привести реальный пример
>> M> когда требуется именно такое поведение как сейчас?

>> сейчас директива listen *:port означает "все остальные ip:port,
>> кроме явно определенных в других директивах server", и это имеет
>> смысл и дает возможность для маневра, когда часть ip - динамические.

M> Так вот, мое предложение состоит в том чтобы выбросить из вашего
M> определения часть "кроме явно определенных в других директивах server".
M> Т.е. будет означать просто "все ip:port".

M> Вы все ещё настаивате на том что сможете привести пример когда такое
M> изменение сделает невозможным определить нужную вам конфигурацию ?
M> Тогда приведите его (пример).

пока подожду ответа на первый вопрос ( про mail.site.com / site.com )
чтобы лучше понять какие именно изменения предлагается внести в nginx.

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

>> если конфиг nginx стал таким большим и сложным, что приходится
>> тратить много времени и сил на поддержание его в актуальном состоянии,

M> Ага, а если не сделать, то искать виртхосты где стояло *:80
M> и заменять один listen на пачку других, как сейчас.

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

кроме того, есть еще один нюанс - listen на явно определенный ip адрес
работает быстрее, чем listen *:80, следовательно, - если задумываться
о максимальной производительности - лучше явно указывать ip адреса.

и я вообще, честно говоря, не понимаю сути этой проблемы с listen *:80;
проблема в том, что приходится много времени тратить на редактирование
конфигурационных файлов в текстовом редакторе, или же проблема в том,
что теперешнее поведение nginx кажется нелогичным и неправильным?

M> ЗЫ: Прошу прощения за резкий тон, не стоит это считать за попытку
M> нанести оскорбление. Рассчитываю на взаимопонимание и конструктивный
M> диалог.

резкий тон конструктивному диалогу не способствует.

-- 
Best regards,
 Gena