Hi, I have configuration with two virtual hosts v1 and v2, both listening on the same IP address. The configuration for the virtual hosts basically looks like this:
Listen: 10.0.0.1:80 http NameVirtualHost 10.0.0.1:80 <VirtualHost 10.0.0.1:80> ServerName v1 DocumentRoot /srv/v1 </VirtualHost> <VirtualHost 10.0.0.1:80> ServerName v2 ServerAlias 10.0.0.1 DocumentRoot /srv/v2 </VirtualHost> For HTTP requests with the request header 'Host: 10.0.0.1:80', the request always ends up on virtual host v1, delivering the content from /srv/v1. This seems to be wrong, but at least it is unexpected. I want to avoid using fully qualified host names as parameters to VirtualHost, because for some reason I can't rely on the host names being present in DNS, which in the worst case would cause the virtual host to be skipped with the following error: Name or service not known: Could not resolve host name v1 -- ignoring! I can re-order the configuration to setup the virtual host v2 with the IP literal as ServerAlias first. This will then work, but I wonder how reliable this would be. >From reading the code (version 2.2.19) I discovered, that in the function check_hostalias() defined in server/vhost.c the host header is matched against the parameter from the VirtualHost container first, before it is then matched against any ServerName or ServerAlias directive. And as soon as the first VirtualHost seems to match, no ServerName or ServerAliases are checked. So, essentially any name or IP literal specified as parameter to VirtualHost seems to have precedence over all ServerName or ServerAlias directives. I've already consulted the SVN history. Apparently this code flow didn't change since the NameVirtualHost directive was added (SVN Rev. 79345) back in October 1997, and maybe is even older. Does anybody know a reason for this code flow? Do you agree that this is something that needs to be fixed? If yes I could start to work on a patch... Regards, Micha