httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: fix_hostname() in 1.3.30-dev broken
Date Mon, 22 Mar 2004 14:40:47 GMT
Roy T. Fielding wrote:
> > Ugg... fix_hostname() in 1.3.30-dev (and previous) are
> > broken such that it does *not* update parsed_uri with
> > the port and port_str value from the Host header.
> > This means that with a request like:
> >
> >     % telnet localhost 8888
> >     GET / HTTP/1.1
> >     Host: foo:9999
> >
> > that the '9999' port value from the Host header is
> > ignored!
> When is fix_hostname() used?  If it is used anywhere other than
> ProxyPass redirects, then it must ignore that port value.  To do
> otherwise would introduce a security hole in servers that rely on
> port blocking at firewalls.  I agree that ProxyPass needs to
> know that port number, but that should be handled within the
> proxy itself.

fix_hostname() is used by ap_update_vhost_from_headers() which is called
immediately after all request headers have been read. The reason is
that we "need" to adjust r->hostname to reflect what was sent
in Host:

Either the behavior in 2.0 is wrong, or 1.3 is, because 2.0
uses the port number provided in Host: to adjust the parsed_uri.port
value, whereas 1.3 does not. And UseCanonicalName explicitly states
that if Off, that Apache will use the Hostname *and* Port provided
by the client, which leads me to think that 2.0 is correct...

Whatever uses ap_get_server_port() would "use" the Port number
included in the Host: header. This includes mod_vhost_alias,
mod_proxy, mod_rewrite and Apache itself when it creates self-
referential URLs (hence UseCanonicalName).

Note that it's ONLY when UseCanonicalName is Off that this is
an issue, and the SysAdmin no doubt has reasons for it :)

   Jim Jagielski   [|]   [|]
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

View raw message