Lane, Ryan wrote:
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 http://wiki.cacert.org/wiki/VhostTaskForce for a discussion of the various ways of achieving this.
-- Tim Starling