Converting Apache configs to nginx, why is a NameVirtualHost workalike is a bad thing?

[Unai Rodriguez]

Having one block per server is the best for performance because you only test a condition once; the way you're doing it would require NGINX to evaluate hostnames twice or maybe more.

In my opinion config maintenance is important as well so either stick to what you have (unless those sites have thousands of requests per second) or generate the configs using Puppet, Chef or the like...




Sent from Samsung Mobile

-------- Original message --------
From: Darren Pilgrim <list_nginx at bluerosetech.com> 
Date:  
To: nginx at nginx.org 
Subject: Converting Apache configs to nginx, why is a NameVirtualHost workalike is a bad thing? 
 
I'm switching some servers from Apache 2.2.x to nginx 1.2.6.  In Apache, 
I use NameVirtualHost.  I also use Rewrite directives to manage www. 
prefixing via a 301 redirect.  All the user has to is create 
/wwwroot/$hostname, upload the site files, and point DNS at my server. 
On my end, all I have to do is create the Apache config once as part of 
the new-user setup.

When I converted that to nginx, this is what I came up with:

root /www/user/wwwroot/$http_host;

For the user who wants to drop the www.:

if ($http_host ~ ^www\.(.+)$) {
return 301 http://$1$request_uri;
}

For the user who wants to always have the www.:

if ($http_host !~ ^www\.) {
return 301 http://www.$http_host$request_uri;
}

Which, in testing, works a treat.  Various articles say this style of 
configuration is bad.  Instead I should:

1. have per-domain server blocks;
2. have a server block for www.example.com that redirects to 
example.com. or vice versa.

In other words, for the user who has 37 domains, I'll need 74 server 
blocks in their nginx config.  That's a significant regression in terms 
of workload and simplicity.

If it's bad, ok, I won't do that; however, I can't seem to find an 
explaination *why* it's bad.  Would someone please clarify that point?

_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130212/12581c34/attachment.html>