On Fri, 13 Dec 2013 10:46:43 +0100
Ruediger Pluem <rpluem@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.