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 Mon, 25 Nov 2013 23:46:00 GMT
On Mon, Nov 25, 2013 at 10:55 PM, William A. Rowe Jr.

> It appears that our SNI hostname comparison is invalid for forward proxy
> applications, specifically proxy CONNECT.  RFC 2616 states;
>   14.23 Host
>   The Host request-header field specifies the Internet host and port
>   number of the resource being requested, as obtained from the original
>   URI given by the user or referring resource (generally an HTTP URL,
>   as described in section 3.2.2). The Host field value MUST represent
>   the naming authority of the origin server or gateway given by the
>   original URL. This allows the origin server or gateway to
>   differentiate between internally-ambiguous URLs, such as the root "/"
>   URL of a server for multiple host names on a single IP address.
> I had read this as proxy host's name in forward proxy applications, but
> reading on, it's clear this is ambiguous;  from RFC 2817
>   5.2 Requesting a Tunnel with CONNECT
>    A CONNECT method requests that a proxy establish a tunnel connection
>    on its behalf. The Request-URI portion of the Request-Line is always
>    an 'authority' as defined by URI Generic Syntax [2], which is to say
>    the host name and port number destination of the requested connection
>    separated by a colon:
>       CONNECT HTTP/1.1
>       Host:
> So we have a clear, RFC-approved example of using the final endpoint as
> the Host: header value, not the intermediate
> In this case, we fail the request because the SNI of the proxy machine
> does not match the Host: of the origin server name.
> 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
 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 SNI
from r->headers_in (when applicable), instead of r->hostname, at least for
the CONNECT and ProxyPassPreserveHost cases?

View raw message