httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William A Rowe Jr <wr...@rowe-clan.net>
Subject Re: svn commit: r1769965 - /httpd/httpd/trunk/server/vhost.c
Date Wed, 16 Nov 2016 13:04:06 GMT
On Wed, Nov 16, 2016 at 1:52 PM, Ruediger Pluem <rpluem@apache.org> wrote:

>
> On 11/16/2016 01:05 PM, wrowe@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.

Mime
View raw message