server_name bug

Eugene Janusov eugene at annah.ru
Thu Oct 30 17:38:06 MSK 2008


On 31.10.08 01:11, Vladimir Rusinov wrote:
> 2008/10/30 Eugene Janusov<eugene at annah.ru>
>
>> Есть некий сервер. У него есть некий фиксированый 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.





More information about the nginx-ru mailing list