Actually cause the Host header to be overridden, as noted by rpluem,

and simplify now that there isn't a log-only mode.

I believe this logic to be busted. Given this request;

GET http://distant-host.com/ 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.




git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1769965 13f79535-47bb-0310-9956-ffa450edef68