This seems like what it does for you is allow a "Host: name" to match the first entry that has no ServerName or ServerAlias, whereas a "Host: address" does not. For me, the exact opposite is happening. You've been using * for the address and I've been using the IP address. Maybe that had an effect for what might well otherwise be "no definite behavior".

I'll add "ServerName default" on the first vhost and see what that does. Maybe that will prevent the "Host: address" case from matching it for me (I didn't have ServerName or ServerAlias at all).


ServerPath is a workaround for getting HTTP/1.0 requests to go to vhosts by providing a path based mechanism to get there. That can have value in many cases. But that's not what I want to do. Instead, in the case of no "Host: anything" being given, I want to deliver a page directing the user to upgrade their browser. That, or deliver a page with some snide remark. Or maybe have it be a secret step to a hidden site. Whatever.

But I can see uses for ServerPath.

If I use NameVirtualHost 192.168.0.77:80, then I see the behavior you mentioned. A request with no "Host:" header points to the vhost with a ServerName 192.168.0.77.
If you are sure it was working in apache 1.x, you may file a bug report to apache and see what they'll answer to you.

You can use mod_rewrite to redirect clients based on their browser "User-agent".

Regards

The request with "Host: <IPaddr>" does NOT got to the vhost with "ServerName <IPaddr>" and instead goes to the first vhost for that IP address ... for me. The vhost with "ServerName <IPaddr>" is apparently unreachable if it is not the first vhost.

Since the description you give for your experience is nearly opposite, I have to conclude Apache has some sort of inconsistent behavior, either due to the differences in the rest of how we configure it, or in the different versions we are using (if any).

Both of our experiences seem not 100% consistent. One or the other case goes to the "wrong" vhost (though Apache developers may insist that it is right). I suspect the situation is the result of the fact that Apache's foundational core logic does not have any concept of virtual hosts, and that this is all an add on. IMHO, if they were to take the dynamic vhost logic they do have, and apply it to actually load host based config files on the fly (e.g. if the memory cached copy of the host config struct has an older date than the host specific config file, that config file is reloaded on the fly), and do all this as the core of a specifically host based server (anyone not wanting host named based would not use this one), they might actually have something that works more solidly and efficiently than the "patchy" mess they have now (but I guess that also means not using the same name).