diff options
author | William A. Rowe Jr <wrowe@apache.org> | 2016-11-16 13:05:53 +0100 |
---|---|---|
committer | William A. Rowe Jr <wrowe@apache.org> | 2016-11-16 13:05:53 +0100 |
commit | 1fea002b502622c7ca949b9223084a5d714d2849 (patch) | |
tree | 9be0029a5f88cb4beebebb72e1a9c09da32c343c /server/vhost.c | |
parent | documentation rebuild (diff) | |
download | apache2-1fea002b502622c7ca949b9223084a5d714d2849.tar.xz apache2-1fea002b502622c7ca949b9223084a5d714d2849.zip |
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
Diffstat (limited to '')
-rw-r--r-- | server/vhost.c | 10 |
1 files changed, 4 insertions, 6 deletions
diff --git a/server/vhost.c b/server/vhost.c index ebf1a995aa..1896595653 100644 --- a/server/vhost.c +++ b/server/vhost.c @@ -1165,13 +1165,11 @@ AP_DECLARE(void) ap_update_vhost_from_headers(request_rec *r) * request line. */ if (have_hostname_from_url && host_header != NULL) { - const char *info = "Would replace"; - const char *new = construct_host_header(r, is_v6literal); - apr_table_set(r->headers_in, "Host", r->hostname); - info = "Replacing"; + const char *repl = construct_host_header(r, is_v6literal); + apr_table_set(r->headers_in, "Host", repl); ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r, APLOGNO(02417) - "%s Host header '%s' with host from request uri: " - "'%s'", info, host_header, new); + "Replacing host header '%s' with host '%s' given " + "in the request uri", host_header, repl); } } |