Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: server_name bug
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
|