httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brad Nicholes" <>
Subject Re: Request for feedback - UseCanonicalPort
Date Wed, 12 May 2004 17:13:37 GMT
    Now I understand better, thanks.  The issue that prompted me to
implement the fixes for 2.1 and 1.3 manifested themselves primarily on
NetWare due to the way NetWare implements the SSL functionality (NetWare
doesn't use mod_ssl).  In some cases requrests on an SSL port were being
redirected to port 80 rather than the port that they came from.  This
problem has been solved in 2.x for NetWare by implementing the
default_port hook in mod_nw_ssl and doing something similar in 1.3.
    It sounds like there are really two issues that need to be
addressed at least for the 2.0 branch although they could be tied
together.  One issue, as you have described, is how or when to use a
port value which UseCanonicalPort would solve.  The other issue, which
has already been address in 1.3 and 2.1, is where to get the port value
from.  Allowing Apache to look at the physical port would need to be
added to 2.0 as it does in 1.3 and 2.1.


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions 

>>> Wednesday, May 12, 2004 7:28:24 AM >>>

On May 11, 2004, at 6:18 PM, Brad Nicholes wrote:

> +1 to Bill's comment.  I don't quite understand what is confusing
> why we would need UseCanonicalPort.  IMO, all that really needs to
> done is to fix UseCanonicalName so that it works according to the
> documentation.  As was explained previously, when UseCanonicalName
> OFF, both 1.3 and 2.1 try to pull the port information from the
> in any way that it can before defaulting to values supplied in the 
> .conf
> file or the hard-coded standard port values.  The problem with the
> tree is that it only looks for the port value as part of the URL
> defaulting to the known values.  Before using known values, it
> look for the port in the connection information (ie.
> r->connection->local_addr->port).  The current result can produce
> incorrect port information when a port value is not supplied as part
> the URL.  According to the documentation, if UseCanonicalName is OFF
> should construct the self-referential information from the client. 
> skipping the port information held in the connection record, it
> doing what it claims to be doing.

The rub is that with UCN Off, we either choose the port number
sent within the Host header or we choose the actual physical
port number; we *never* choose the configured or default port.
The docs say:

   With UseCanonicalName off Apache will form  self-referential
   URLs using the hostname and port supplied by  the client if any
   are supplied (otherwise it will use the  canonical name, as
   defined above).

which is does not do currently but *is* a viable and required
implementation in some cases, as you know since IIRC you
were the one to adjust 2.1 to the current behavior to
correctly handle some problems you were seeing. However,
the 2.0 case is also required when Apache (on port 8000, eg)
is behind a load-balancer (on port 80) and the LB splices
the request to Apache. In this case, if Apache needs to
create a self-ref with UCN Off, then it returns the
hostname from Host (as it should) but assuming no port
information it returns port 8000:


Apache should send, but instead
it'll send unless the client
appends ':80' to the Host header :/

So both the 1.3/2.1 and the 2.0 methods may be required
for different environments. Which means that at least
there should be a 4th option (after On, Off and DNS) which
says "Ignore physical port" or alternatively "Use physical
port". But use_canonical_name is a bitfield of width 2,
which doesn't give us enough room, so in order to prevent
breaking the API (we can't expand it), we could tack another
element to the end of core_dir_config to extend how the
port is determined, hence UseCanonicalPort.

View raw message