Hi. vhosts/name-based.html says: > The complete list of names in the VirtualHost directive are treated just like a (non wildcard) ServerAlias. and vhosts/details.html says: > The complete list of names in the VirtualHost directive are treated just like a (non wildcard) ServerAlias (but are not overridden by any ServerAlias statement). 1) First, the wording here is a bit strange, especially the "(non wildcard)"... no sure what that really tries to tell here, as a domainname in VirtualHost couldn't contain a wildcard anyway? If it means that *:* or *:80 doesn't implicitly add "*" as a ServerAlias, that should be made more clear. But from my testing it rather means that any name where the port is "*", like "example.com:*" wouldn't get added. 2) Second and more important, the described behaviour seems only half the truth. From my live tests it seems that a (Server)Alias is only added for accesses made on the port that is given together with the domainname in <VirtualHost>. Consider the following example in that order: (with foo.example.com pointing to 10.10.10.10 in DNS) VirtualHost 10.10.10.10:80 10.10.10.10:8080> ServerName default-vhost.example.com ... </VirtualHost> VirtualHost 10.10.10.10:80 10.10.10.10:8080 foo.example.com:80> ServerName other-vhost.example.com ... </VirtualHost> An access to foo.example.com:80 will end up on other-vhost, but(!) an access to foo.example.com:8080 ends up on default-vhost ... which is unexpected as other-vhost also listens on 10.10.10.10:8080 and allegedly the domainname from it's VirtualHost would have been added as ServerAlias. But it's apparently not generally added, *but only* for the indicated port. Cheers, Chris
I took a crack at this in http://svn.apache.org/viewvc?rev=1884555&view=rev should be published on https://httpd.apache.org/docs/trunk/vhosts/name-based.html soon
Hmm yeah, that seems ok-ish, at least for (2). I'd perhaps change: > and the hostname:port > combination is also checked prior to ServerName and ServerAlias > checks for name-based virtual host > resolution. to > and the hostname:port combination (if neither hostname nor port is the wildcard) > is also checked (prior to names in ServerName and ServerAlias) > for name-based virtual host resolution. It does however not deal with (1) which I'd have done above with "(if neither hostname nor port is the wildcard)" And generally, hostname is also a bit ambiguous, since these names are not necessarily canonical hostnames (actually that's what vhosting is all about) but rather domain names. Apart from that, maybe it's actually the behaviour that should be changed for (2): AFAIU, a vhost has two properties here: a) the address/port combinations it would apply to b) the domainnames matched against the HTTP Host header. (a) is set with <VirtualHost>, (b) with ServerName/ServerAlias. It's a bit strange that for the names set via ServerName/ServerAlias any addr/port matched by the vhost fit, but not for the - conceptually identical - names set via <VirtualHost>. Cheers, Chris.
Oh and all that is now in vhosts/name-based.html, but missing in vhosts/name-based.html. It's a bit unfortunate that the whole system (which is actually not that extremely difficult) is scattered over so many places. In fact, conceptually it seems that httpd doesn't differ between IP-based and name-based at all. It's always just: 1) first take any vhosts whose addr:port match literally (i.e. no wildcard) 2) if none, take also those with wildcards) 3) if there is a HTTP Host Header, match that in the remaining vhosts and fall back to the first one if no-one matches or there is none. 4) if there was matching no vhost at all, give it to the main server Apart from some details, like where to get default ServerName/Alias from,... or the thing with the implicitly added ServerAlias from <VirtualHost>,... that's it, isn't it? In the documentation there seem currently a lot of text writing "around" these simple rules.
(In reply to Christoph Anton Mitterer from comment #2) > Hmm yeah, that seems ok-ish, at least for (2). > > I'd perhaps change: > > and the hostname:port > > combination is also checked prior to ServerName and ServerAlias > > checks for name-based virtual host > > resolution. > This sentence begins with "when a hostname is specified" so I prefer to not make it any longer / more complicated. -/- I don't think many readers will be confused by hostname vs. domain name. I think "hostname" is actually more accessible to a casual user. -/- > Apart from that, maybe it's actually the behaviour that should be changed > for (2): I think there would have to be a really compelling reason to change behavior in this area. You may want to make a standalone argument in a standalone issue that considers externals and migration as opposed to some ideal behavior.