httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <>
Subject Re: svn commit: r1768036 - in /httpd/httpd/branches/2.4.x-merge-http-strict: ./ CHANGES include/ap_mmn.h include/http_core.h include/httpd.h modules/http/http_filters.c server/core.c server/protocol.c server/util.c server/vhost.c
Date Wed, 16 Nov 2016 13:01:22 GMT
On Wed, Nov 16, 2016 at 1:32 PM, Ruediger Pluem <> wrote:

> On 11/16/2016 01:08 PM, William A Rowe Jr wrote:
> >
> > Here's why I think the whole logic is busted and the preserve
> r->hostname is
> > the right thing to do for the outer request (not a child/client request
> to any
> > backend host)...
> >
> > I believe this logic to be busted. Given this request;
> >
> > GET HTTP/1.1
> > Host: proxy-host
> >
> > we would now fail to evaluate the proxy-host virtual host rules.
> >
> > This seems like a breaking change to our config. mod_proxy already
> > follows this rule of RFC7230 section 5.4;
> >
> >    When a proxy receives a request with an absolute-form of
> >    request-target, the proxy MUST ignore the received Host header field
> >    (if any) and instead replace it with the host information of the
> >    request-target.  A proxy that forwards such a request MUST generate a
> >    new Host field-value based on the received request-target rather than
> >    forward the received Host field-value.
> >
> > Section 5.5 of RFC7230 has this to say;
> >
> >    Once the effective request URI has been constructed, an origin server
> >    needs to decide whether or not to provide service for that URI via
> >    the connection in which the request was received.  For example, the
> >    request might have been misdirected, deliberately or accidentally,
> >    such that the information within a received request-target or Host
> >    header field differs from the host or port upon which the connection
> >    has been made.  If the connection is from a trusted gateway, that
> >    inconsistency might be expected; otherwise, it might indicate an
> >    attempt to bypass security filters, trick the server into delivering
> >    non-public content, or poison a cache.  See Section 9 for security
> >    considerations regarding message routing.
> >
> > Section 5.3.1 states;
> >
> >    To allow for transition to the absolute-form for all requests in some
> >    future version of HTTP, a server MUST accept the absolute-form in
> >    requests, even though HTTP/1.1 clients will only send them in
> >    requests to proxies.
> >
> > It seems to me we should simply trust the Host: header and dump this
> whole
> > mess. If we want to reject requests in absolute form after the proxy
> modules
> > have had a chance to accept them, that wouldn't be a bad solution.
> Hm. I am confused now. 5.3.1 seem to state that we need to accept them in
> any
> case, even for non proxy requests. For the proxy case 5.4 seems to be
> pretty clear
> what to todo: Forget about the Host header, take it from the request.
> For the other case we can IMHO decide what we want to do accept it (but
> what has
> precedence in this case host or request) or drop / error out. I guess both
> behaviours
> can make sense. The later one as a security check, the former one if we
> are on a backend
> system and have a trusted proxy / reverse proxy aka gateway in front of us.

We need to tolerate their presence. But we should ignore the guidance that
sf originally quoted, that the URI host supersedes the Host header, it does
not, they are two different entities it the proxy case, and in the non-proxy
local resource case, a mismatch makes no sense in the first place.

We could reject non-proxy requests in absolute form if they were to some
local resource, but I think that is punitive. I'm not aware of any server
would refuse a request for ...

We could reject non-proxy requests in absolute form if the URI host did
not match the specified Host: value. I'd initially wished it would, since
these are logged as 404's and typically searches for open proxies. That
confuses every new user/admin. But what about a client which resolved
the uri as submitted but then generated the Host: after some dns fixup?

Or we could continue to discard the target host specified in the local
resource uri, as we do today.

Can we get more eyeballs on this? Before backporting anything, I'd like
to eliminate this specific test altogether from the backport, or at least
refine it to be something meaningful.

View raw message