Item11055: add support for server aliases

... to reuse the same instance under several names.

Server aliasing normally would be possible by adding symlinks in the vhosts directory, for instance by creating a symlink from localhost to 127.0.0.1. For VirtualHostingContrib the new directory would then look like another vhost available now. However when running a command on each of the available vhosts (using run_on_all()) the command would be executed twice ... which you'd better avoid as the first run already completed the job.

The patch below adds a new configuration variable: a hash map from alias name to real hostname:

--- lib/Foswiki/Contrib/VirtualHostingContrib/VirtualHost.pm    (revision 12344)
+++ lib/Foswiki/Contrib/VirtualHostingContrib/VirtualHost.pm    (working copy)
@@ -22,7 +22,9 @@
 
   # check whether the given virtual host directory exists or not
   if (!$class->exists($hostname)) {
-    return undef;
+
+    $hostname = $Foswiki::cfg{VirtualHostingContrib}{ServerAlias}{$hostname};
+    return undef unless defined $hostname;
   }

Antonio, while I already checked in this patch, feel free to kick my a* if you don't like it or have other thoughts on it.

-- MichaelDaum - 20 Aug 2011

Hey Michael.

For production use I think that being able to access the same instance over different hostnames is not a good idea: caches that relly on the hostname get duplicated, if you use SSL one of the domains will appear as not having a proper certificate, it pollutes your access logs, etc. What I usually do is to keep one canonical hostname, and configure the webserver to do redirects to it from all alternate domains.

That said, I don't have strong feelings against having this patch in, as long as it is documented along with these concerns I wrote above. Would you be willing to document this feature and add some automated tests?

-- AntonioTerceiro - 20 Aug 2011

I agree on better using redirects and things. For me there are actually two real-life reasons to use server aliases: (1) the same server is reachable on a nother network; so redirecting is no option (2) before deploying a new virtual host, I'd like to build it up on a test domain that differs from the production domain name; when done the vhost is synced over to the network where it is used in production.

-- MichaelDaum - 25 Aug 2011

Well, as I said above, I'm ok with this feature as long as my concerns are documented. I don't have the time nor the motivation to do it myself for now, but by all means go ahead.

-- AntonioTerceiro - 29 Oct 2011

Released as 1.0.0

-- MichaelDaum - 04 Jul 2012