Item11055: add support for server aliases

pencil
Priority: Enhancement
Current State: Closed
Released In: n/a
Target Release: n/a
Applies To: Extension
Component: VirtualHostingContrib
Branches: trunk
Reported By: MichaelDaum
Waiting For:
Last Change By: MichaelDaum
... 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
Topic revision: r8 - 04 Jul 2012, MichaelDaum - This page was cached on 24 May 2019 - 17:58.

The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy