server_name bug

[Vladimir Rusinov]

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?


-- 
Vladimir Rusinov
http://greenmice.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx-ru/attachments/20081030/43cb6b69/attachment.html>