Daniel Rogers wrote:
However, this seems like an artifact of the config file data data
organization and/or an apache implementation limitation, rather than a
limitation on the protocol itself.
I would just ignore the troll, but you have put the time into trying to
think this through, so we repeat...
Client Server
request handshake --> acknowledge handshake
negotiate keys and credentials
connection secure <-- complete handshake
now encrypted...
send headers (Host:) --> read headers, choose a virtual host
read response <-- prepare response
The client and server agreed upon a certificate before Host: was seen.
No problem, right? Only issue is for the client, it thinks that example.com
isn't example.net as recorded in the common name. We can't vary on Host:
before we see Host:, and we won't see Host: till handshake is complete.
Stop bitching about a 10 year old spec. It's trivial, use a modern browser
(beyond today - none exist yet) that can do Connection-Upgrade and agree
about the text of the headers before the ssl handshake is performed. The
browser people haven't caught up, because it's a non-trivial problem to
represent that the agreed-upon connection is secure to the user, or that
a secure connection is available to be toggled, or whatever. These aren't
https:// requests, they are http:// with extra semantics. Modern clients
such as remote printing over http and neon/curl libraries already support
it now, IIUC. As does httpd 2.2.
