+1 to Bill's comment. I don't quite understand what is confusing and why we would need UseCanonicalPort. IMO, all that really needs to be done is to fix UseCanonicalName so that it works according to the documentation. As was explained previously, when UseCanonicalName is OFF, both 1.3 and 2.1 try to pull the port information from the client 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 2.0 tree is that it only looks for the port value as part of the URL before defaulting to the known values. Before using known values, it should 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 of the URL. According to the documentation, if UseCanonicalName is OFF it should construct the self-referential information from the client. By skipping the port information held in the connection record, it isn't doing what it claims to be doing.
Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com >>> [EMAIL PROTECTED] Tuesday, May 11, 2004 2:36:29 PM >>> Jim, would you post a chart of the now-three proposed behaviors, with the various effects broken out? It would help us all understand why we need a third way. Bill At 02:53 PM 5/11/2004, you wrote: >IMO, we need more control over the port number that Apache >determines to be canonical beyond that which is provided >by UseCanonicalName, simply because there are so >many options and permutations which are possible >and applicable for different environments. > >To that end, instead of overloading UseCanonicalName >(and breaking the API), I'm working on UseCanonicalPort. >Before I spend lots of time on this, I need to >get a feel for whether this is an itch others >think need scratching and would vote for including >in 2.0 (I'm working on 1.3, 2.0 and 2.1 patches)... >
