ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
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 31.10.08 01:11, Vladimir Rusinov wrote:
2008/10/30 Eugene Janusov<eugene@xxxxxxxx>

Есть некий сервер. У него есть некий фиксированый ip (в его локальную сеть)
и несколько штук динамических (тунели в untrusted сети).
Нужно чтобы некий ресурс открывался только с этого фиксированного ip, и
некие ресурсы, которые открывались бы со всех ip.

Вполне реальная ситуация, и через некоторое время такая может возникнуть и
у
меня.

Сейчас это делается легко, понятно и логично:

server {
   listen 1.2.3.4:80;
   server_name my_internal_site;
}
server {
   listen *:80
   listen 1.2.3.4:80;
   server_name my_public_site;
}
server {
   listen *:80
   listen 1.2.3.4:80;
   server_name my_public_site2;
}

А как этой конфигурации помешает, если * станет полноценным wildcard'ом?
Можно будет избавиться от указания второго listen для публичных ресурсов.


А откуда nginx узнает во что этот * разворачивать?
Особенно если интерфейсы поднимаются как до, так и во время работы nginx?

А сейчас откуда знает и как реагирует на поднятие новых интерфейсов?

На сколько представляю, и как уже сказали выше, полноценный wildcard внутренне будет заменяться на все доступные IP.

--
Best regards,
Eugene Janusov.



 




Copyright © Lexa Software, 1996-2009.