Arbitrarily slicing $server_name into subdomains?

[merlin corey]

On Thu, Jan 14, 2010 at 2:32 PM, Igor Clark <lists at ruby-forum.com> wrote:
> merlin corey wrote:
>
>>> Hint: In your application and just pass the full domain to it ;)
>>>
>>> -- Merlin
>>>
>>
>> To clarify, "your application" is some mythical and simple application
>> that just does routing the way you want.  20 line or less python
>> script including the fastcgi and daemonize ;).
>>
>> -- Merlin
>
> Thanks Merlin. Part of the point is to be able to run code unmodified in
> various environments, inside dynamic vhosts using wildcard DNS. Do you
> mean as a 3rd layer between nginx and the web app?
>
> Cheers
> Igor Clark
> --
> Posted via http://www.ruby-forum.com/.
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://nginx.org/mailman/listinfo/nginx
>

I don't personally like or support the idea of overcomplicating the
configuration for a false perception of simplicity...

The BEST solution, in my opinion, is to generate static server blocks
for each known domain and regenerate configuration as needed (when a
new document root is created, the new server is created too).

Still, for the arbitrary subdomains, instead of trying to shoe-horn it
into this unnecessary heirarchical organization you just do a simple
flat mapping of subdomains to directories, like so:

server {
  listen 80;
  server_name ~^(.*)\.mydomain.tld$;
  root /var/www/mydomain.tld/$1/public;
}

If you do it in the manner you can support arbitrary length
subdomains.  For example...

sub.mydomain.tld -> /var/www/mydomain.tld/sub/public
a.b.mydomain.tld -> /var/www/mydomain.tld/a.b/public
i.complicate.configs.mydomain.tld ->
/var/www/mydomain.tld/i.complicate.configs/public

Essentially, there is no reason to think of the dot separator in
domain names as equivalent to a directory hierarchy other than that it
is comfortable.

-- Merlin