Re: server_name bug

[MZ <zuborg@xxxxxxxxxxxxxxxxxxx>]

В чт, 30/10/2008 в 17:28 +0200, 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)

Очевидно, что mail.site.com матчится и mail.* и *.site.com, то есть
обоими виртхостами. Чтоб разрешить эту неопределенность, необходимо в
нужный виртхост дописать server_name mail.site.com, то есть указать
указать какому виртхосту дать приоритет именно для этого домена. Либо
определить приоритет *. по сравнению с .* . Другого пути нет.
Использовать для разрешения неопределенности ip домена считаю
неправильным подходом.

site.com не матчится *.site.com, но матчится вторым виртхостом, тут
никаких вопросов.

Что касается запроса site.com на ип 10.20.30.50 - поскольку он не
матчится ни одним server_name ни в одном виртхосте, он должен попасть в
default (первый) виртхост описаный для listen 10.20.30.50, либо (если
предыдущий не описан) - в default (первый) виртхост для *:80 .

Может возникнуть вопрос - а почему тут приоритет дается виртхосту с
указаным 10.20.30.50 в ущерб *:80 ? Лично мне оба варианта (что с
приоритетом, что без) - кажутся не очень востребованными в реальных
ситуациях, поскольку никак не используют хидер Host: . Но вариант с
приоритетом ипа над * дает больше гибкости.


> очень хотелось бы узнать ответ для всех 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 игнорирует виртхосты *:80, когда
есть оные с listen 1.2.3.4:80 для запросов, которые приходят на 1.2.3.4
и с заголовком Host: , который матчится только виртхостом *:80.

Мое предложение состоит в том чтобы хидер Host: проверять не только для
тех виртхостов в которых указан listen 1.2.3.4 (разумеется, мы
рассматриваем случай когда запрос пришел именно на IP 1.2.3.4), но и (в
случае, если ни один server_name в предыдущих виртхостах не матчит
Host:), также виртхосты с listen *:80.

Если есть два виртхоста, один listen 1.2.3.4, а второй listen *:80 -
разумеется приоритет должен даваться первому.
Но если виртхоста с listen 1.2.3.4 который матчит Host: нет, но зато
есть! виртхост с listen *:80 и который таки матчит Host: - то приоритет
должен даваться последнему.

Прошу прощения что столько раз разжевываю эту ситуацию - просто чтоб не
возникало вопросов.


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

Гораздо удобнее не писать скрипт и не иметь необходимости менять все
виртхосты после добавления нового.

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

Производительность в ущерб правильности работы - это нонсенс.

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

второе.

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

Просто надоело. Все уперлись в сокеты как будто именно в них все дело.
Решение в какой виртхост отправлять запрос принимает nginx, а не сокеты.