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

Reply via email to