httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Tue, 26 Nov 2013 08:29:44 GMT
On Tue, Nov 26, 2013 at 6:31 AM, Kaspar Brand <>wrote:

> On 26.11.2013 00:46, Yann Ylavic wrote:
> >> Ideas for the appropriate patch to httpd?  Scope this fix to CONNECT
> >> requests alone, or all forward proxy requests?
> >>
> >>
> > Maybe all forward proxy modules are concerned.
> > There is PR
> > 55782
> >  which I started to debug but did not finish (run out of time).
> > From there it looked like ProxyPassPreserveHost may cause problems too
> > with SNI (not sure yet).
> >
> > Anyway, shouldn't the proxy code(s) use the Host header to fill in the
> > from r->headers_in (when applicable), instead of r->hostname, at least
> for
> > the CONNECT and ProxyPassPreserveHost cases?
> AFAICT, this was the idea in the original patch for PR 53134, but a
> "slightly different approach" was then committed (r1333969).
> As far as PR 55782 is concerned, the problem might be that
> proxy_util.c:ap_proxy_determine_connection() does not take Host: header
> differences into account when checking if an existing connection can be
> reused (not sure). With SNI this would have the effect that the hostname
> from the TLS handshake is causing the mismatch with the Host: header.

ap_proxy_determine_connection() should only care about IP:port reuse,
which can be even if the Host has changed.

But indeed the Host is really what the origin server will use, so IMHO
this is the one to use for SNI in proxy_http_handler (should it differ from

Another point is that SNI can not be an IP address according to the RFC
6066 :

3.  Server Name Indication
   Literal IPv4 and IPv6 addresses are not permitted in "HostName".

and this is not specifically checked by mod_proxy before filling SNI.

Shouldn't the SNI be ommited when the Host is missing/empty or an IP
address too?

> Kaspar

View raw message