On Wed, Nov 16, 2016 at 1:52 PM, Ruediger Pluem <rpl...@apache.org> wrote:
> > On 11/16/2016 01:05 PM, wr...@apache.org wrote: > > Author: wrowe > > Date: Wed Nov 16 12:05:53 2016 > > New Revision: 1769965 > > > > URL: http://svn.apache.org/viewvc?rev=1769965&view=rev > > Log: > > 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. > > > > Modified: > > httpd/httpd/trunk/server/vhost.c > > > > Modified: httpd/httpd/trunk/server/vhost.c > > URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/server/ > vhost.c?rev=1769965&r1=1769964&r2=1769965&view=diff > > ============================================================ > ================== > > --- httpd/httpd/trunk/server/vhost.c (original) > > +++ httpd/httpd/trunk/server/vhost.c Wed Nov 16 12:05:53 2016 > > @@ -1165,13 +1165,11 @@ AP_DECLARE(void) ap_update_vhost_from_he > > * 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); > > IMHO the old code was wrong because r->hostname misses the surrounding [] > in case of IPV6 literals, > but otherwise I see no change in logic here: Host part of the request > still takes precedence over Host header. > Ok, I misread your original post, I thought you were pointing out that r->hostname is the Host: header value. > > - 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); > > } > > } > > > > > > > > > > Doesn't this need to get added to the large conformance backport proposal? Added, or discarded entirely, let's resume on the other discussion thread.
