summaryrefslogtreecommitdiffstats
path: root/server/vhost.c
diff options
context:
space:
mode:
authorWilliam A. Rowe Jr <wrowe@apache.org>2016-11-16 13:05:53 +0100
committerWilliam A. Rowe Jr <wrowe@apache.org>2016-11-16 13:05:53 +0100
commit1fea002b502622c7ca949b9223084a5d714d2849 (patch)
tree9be0029a5f88cb4beebebb72e1a9c09da32c343c /server/vhost.c
parentdocumentation rebuild (diff)
downloadapache2-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 'server/vhost.c')
-rw-r--r--server/vhost.c10
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);
}
}