I have Debian 7 on my server matteosistisette.com # cat /etc/hostname matteosistisette.com Here are the contents of my available sites at /etc/apache2/sites-available: /etc/apache2/sites-available/default: http://pastebin.com/Zee7vLw5 /etc/apache2/sites-available/interferencesweb.org: http://pastebin.com/DErqjgke /etc/apache2/sites-available/matteosistisette.com http://pastebin.com/ZSqmVYpZ /etc/apache2/sites-available/sixty-seven.com http://pastebin.com/fkC9Cdfh If I enable all of them EXCEPT DEFAULT, everything works as expected: if a client requests matteosistisette.com it gets matteosistisette.com, if it requests interferencesweb.org it gets interferencesweb.org, and so on. However, if a client requests directly the server's IP, or a domain that points to the server's IP but is not any of the virtual hosts, the server looks for the content in interferencesweb.org's root. Which is expected, I guess, being the first one it's the first. So, IF I ENABLE all of them, INCLUDING DEFAULT the issue appears: * Expected behavior: - if the client requests matteosistisette.com it should get matteosistisette.com, if the client asks interferencesweb.org it should get interferencesweb.org, and so on, but - if it asks the IP directly, or a domain pointing to the IP that is not any of the virtual hosts, then it should get the content at /var/www (which is the default "it works!" page, but I intend to change it). * Observed behavior: - virtual hosts EXCEPT matteosistisette.com work as expected, i.e. if you request sixty-seven.com you get sixty-seven.com, if you request interferencesweb.org you get interferencesweb.org, ... - however, if you request matteosistisette.com (I guess because it is the one that matches the host name in /etc/hostname), the default site is used instead of using the one whose ServerName or alias matches the request.
Unfortunately from a httpd perspective, this is working as designed, for the reason you suggested at the end of your report. If you omit the servername, it's calculated from the system hostname (double-reverse DNS lookup of the system hostname). The docs do not get this exactly right. The alternatives as a default behavior all seem too problematic to be viable options: * httpd could look for a matching servername in a way that the default name-based vhost is not checked first (surprising change for basic function, potentially more costly at runtime) * httpd could use a dummy value rather than the system hostname as a default I think it is necessary for the user to explicitly provide an alternative ServerName in this case. I will take a todo to mention it in ServerName and name-based vhosting docs. Even with the debian "default" virtualhost structured this way, it does not seem to be a frequent problem, so I think it will have to remain the affected users providing an alt ServerName.
> If you omit the servername, it's calculated from the system hostname > (double-reverse DNS lookup of the system hostname). But I'm NOT omitting it. If I do a request without any host, or with a host that does not match any virtual host, I get the default host, that's the expected part. But I do a request to matteosistisette.com, e.g. a "GET /" request with "Host: matteosistisette.com" in the header (I've checked in the browser's developer tools and the header _is_ present). So, it should hit the virtualhost that has ServerName matteosistisette.com rather than the default one. > The docs do not get this exactly right. Then at least the docs must be fixed. Everything I read in the docs, and even the tutorial, are pretty clear in (wrongly) suggesting that a VirtualHost definition whose ServerName matches the host being requested will be used, and that is not the case. I still don't understand why it shouldn't prevail over the default, but alas, it's very important that it is documented. Wait a moment, "I think it is necessary for the user to explicitly provide an alternative ServerName in this case" Are you talking about specifying a ServerName in the definition of the default site? How would that produce the desired result? Suppose the client requests the IP directly, or a host that (through DNS) points to the server but doesn't match the servername of any vhost (not even the default's one). How is it that this would hit the default vhost??
(In reply to teo8976 from comment #2) > > If you omit the servername, it's calculated from the system hostname > > (double-reverse DNS lookup of the system hostname). > > But I'm NOT omitting it. I meant in your default vhost, not in the HTTP request.
> I meant in your default vhost, not in the HTTP request. Yeah, later I realized. But still, see my last question. (and most of my last comment)
> Are you talking about specifying a ServerName in the definition of the > default site? How would that produce the desired result? > Suppose the client requests the IP directly, or a host that (through DNS) > points to the server but doesn't match the servername of any vhost (not even > the default's one). How is it that this would hit the default vhost?? The first-listed vhost captures anything that doesn't match a servername/serveralias, even if you specify a servername.
Ok so the workaround is pretty stright-forward, but this definitely needs to be properly documented. I notice the bug is set as wontFix. Is the documentation issue tracked somewhere else? This lack of documentation is a major source of waste of time, and of questions on StackOverflow/ServerFault/Whatever, most of them without answer.
The doc is updated for 2.4 and trunk to caution against omitting the servername updated: core.html name-based.html I'd suggest opening a debian/ubuntu bug for them to consider the downside in the default virtual host not having a ServerName (can't easily override it with a later vhost which would be quite natural). They probably have more experience with the impact/options around that omitted ServerName.