bug with variables in fastcgi_pass

[Samuel Vogel]

Igor Sysoev schrieb:
> On Mon, Dec 22, 2008 at 03:25:04PM +0100, Samuel Vogel wrote:
>
>   
>> Samuel Vogel schrieb:
>>     
>>> Hey Igor,
>>>
>>> I think I have hit a bug while trying out the feature you added in 
>>> 0.7.27.
>>>
>>> My config looks like this:
>>> server {
>>>   listen 127.0.0.1:81;
>>>   server_name _;
>>>     access_log  /var/log/nginx/access.log;
>>>
>>>   set $subdir "default";
>>>
>>>   if ($host ~ "^(.+)\.user\.domain\.net$") {
>>>       set $subdir $1;
>>>   }
>>>
>>>   root   /www/$subdir;
>>>   index  index.php index.html index.htm;
>>>     location ~ \.php$ {
>>>       fastcgi_pass   unix:/var/run/php-fpm/socket-$subdir;
>>>   }
>>> }
>>>
>>>
>>> And I get the following error:
>>> [error] 17238#0: *1 no resolver defined to resolve 
>>> /var/run/php-fpm/socket-345232, client: 127.0.0.1, server: _, request: 
>>> "GET /info.php HTTP/1.1", host: "345232.user.domain.net"
>>>
>>> If I remove the variable from fastcgi_pass everything works fine!
>>> It seems like nginx is ignoring that I try to point it to a unix 
>>> socket, when I use a variable!
>>>
>>> Regards,
>>> Samy
>>>       
>> Hey Igor,
>>
>> I have just tried to 0.7.26 with the patch you sent to the list and I do 
>> get the exact same error:
>>
>> 2008/12/22 14:05:45 [error] 23482#0: *2 no resolver defined to resolve 
>> /var/run/php-fpm/socket-345232, client: 127.0.0.1, server: _, request: 
>> "GET /info.php HTTP/1.1", host: "345232.user.domain.net"
>>
>> Maybe this helps to isolate the issue a bit!
>>     
>
> fastcgi_pass currently does not support variables for unix sockets:
> it tries to resolve it as domain name. I will try to fix the bug before
> vacantion
This would be great, since this is what we need the variable support for!
Thanks!

Regards,
Samy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://nginx.org/pipermail/nginx/attachments/20081222/095ec603/attachment.html>