On Fri, 13 Dec 2013 10:46:43 +0100 Ruediger Pluem <rpl...@apache.org> wrote:
> William A. Rowe Jr. wrote: > > > > Yes, and? Why would this differ from the historical handling of the > > Host: header? The HTTP Host header is not the dns name of this hop, > > It doesn't, but we clearly stated in the docs before: Don't use name > based virtual hosting with SSL for exactly this reasons. And the issue discussed in the top post has nothing to do with name based virtual hosting, the same problem persists in IP/port-based election of a forward proxy host. > > but the hostname component of the uri. This logic has completely > > broken forward proxies in httpd on the 2.4 and 2.2.25 releases. > > How does this break forward proxies? Usually you connect to a forward > proxy via HTTP. How does SNI matter here? You are connecting to your proxy via https://, I hope. The current browsers are sending the dns name of the proxy via SNI (I have not experimented with them all to determine what they do if you specify an IP address as a proxy host - according to spec no SNI extension should be sent - but that shouldn't be necessary to work around our broken server). The client sends the hostname [+possibly the port] of the requested http or httpd page or back-end CONNECT target as the Host: header. And there we die.
