On Thu, 12 Dec 2013 08:46:32 +0100 Peter Sylvester <peter.sylves...@edelweb.fr> wrote:
> > The rest of the SNI hostname processing steps are where the problem > > lies. We still need to perform http headers -> vhost translation > > after the connection is established. If there's any desire to do > > SNI hostname validation, that has to be limited to comparing that > > hostname to the ServerName/ServerAlias entries, not to the HTTP > > Host: which has a different semantic meaning and is the only > > hostname of interest to httpd as an HTTP server. > this part was always a bit strange: the initial idea was: When the > code sees the Host: and when there was no sni, to force a > renegotiation with the right cert/key. That doesn't doesn't as user agents won't proceed with a request because they had not established trust, and the user agent then rightfully ends this attempt with an error (or sufficiently painful 'ignore this error' action on the part of the user). But again, the Host: field is not defined as the dns name of this next-hop server, but the hostname component of the requested URI.
