HTTPS
does support virtual hosting. You can have certificates
with wildcards, e.g. *.wikipedia.org, and you can even have
certificates that list multiple second-level domains. In
theory we could even support
https://en.wikipedia.org/, by
having LVS pass the traffic off to an SSL proxy cluster,
which forwards to the Florida squids via a secure tunnel.
From what I've read HTTPS does not support name-based virtual hosting,
only IP based virtual hosting, as the SSL connection happens before the
request is made. So, if you have two virtual hosts such as:
<Virtualhost en.wikipedia.org>
...
</Virtualhost>
<Virtualhost de.wikipedia.org>
...
</Virtualhost>
The first virtual host will always be used as the server has absolutely
no clue, when the connection is made, which virtual host it needs to
use.
I believe this is the point Neil was trying to make.
The same is true of unencrypted HTTP. The server has no idea, when the
connection is made, what virtual host will be required. That only comes
when the client sends the Host header.
The issue is that with HTTPS, the server has to send a certificate before
the client sends the Host header. The certificate has to match the hostname.
See
for a discussion of the
various ways of achieving this.
-- Tim Starling