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
parent
c8c36ce7
Please register or sign in to comment