httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Request for feedback - UseCanonicalPort
Date Wed, 12 May 2004 19:14:00 GMT
Well, at least with 2.0, that's the way ServerName is

nd is right... the actual physical port can never be, afaik, 0,
so wherever that is in the logic path, that's the final end :)

But on thinking it even more deeply, having Apache return
the physical port can always be done via setting it
explicitly in ServerName (for 2.x) or adding a Port
directive to the <VirtualHost> tag for 1.3... Many
people may not be aware that:

       Port 8080
         ServerName foo
         Port 80

is possible and legal in 1.3 and makes the Vhost
return foo:80 with UCN On and, with UCN Off will
force Apache to set the port to 80 if the
client doesn't add one to Host. So if with UCN Off
they want the physical port to be sent, ensure
the value for Port is whatever the actual listening
port is; if they want some other port, then it
can be set. But it doesn't cause the Vhost to actually
*do* anything on port 80.

On May 12, 2004, at 2:47 PM, Brad Nicholes wrote:

> I guess the part that confuses me most is why is honoring the physical
> port number a bad thing?  If you look at the implementation of
> ap_get_server_port() in the 2.0 branch, the function determines the 
> port
> value by:
> 1- parsed_uri.port
> 2- server->port
> 3- ap_default_port()
> 1- server->port
> 2- local_addr->port
> 3- ap_default_port()
> Notice that in the USE_CANONICAL_NAME_ON it checks the physical port
> before calling ap_default_port() but USE_CANONICAL_NAME_OFF || DNS
> doesn't.  Shouldn't the sources of port information be the same for 
> both
> cases, just a different order?  The patch in the 2.1 branch just fixes
> this.  But, it was pointed out by nd that if the local_addr->port could
> never be 0 then the call to ap_default_port() is dead code and would
> never be called.  But if it could be 0 then what is the difference
> between no port and a valid port value of 0.  This is the reason why 
> the
> backport proposal has stagnated in the STATUS file.  I don't know what
> the correct answer is but I do believe that honoring the physical port
> number is a good thing and should be checked somehow.

View raw message