Brad Nicholes wrote:
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
On May 11, 2004, at 6:18 PM, Brad Nicholes wrote:
+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
On May 11, 2004, at 9:53 PM, Jim Jagielski 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
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
Do you mean that 2.0 now works correctly? In that case
maybe the short-term is to use the 2.0 method for both
1.3 and 2.1, until we can figure out a better
method... I think the 2.0 method is likely more
correct than the 1.3/2.1 one, at least as a default
implementation.
On May 12, 2004, at 1:13
It works correctly for the NetWare SSL case that I was running into.
But I don't think it works correctly for the case that you are
describing. The patches that I added to 2.0 and 1.3 are NetWare
specific. The 2.0 patch is in mod_nw_ssl.c which implements the
default_port hook and the 1.3 patch
What I've done, for the 1.3 case, is make honoring the
physical port number (ala 2.1) a compile-time flag...
This should hold us off until we figure out a better
way to do this, so it may get backed out when
that happens. In the meantime, 1.3.32-dev will
operate as does 2.0, which is, I think, the
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:
USE_CANONICAL_NAME_OFF || USE_CANONICAL_NAME_DNS
1- parsed_uri.port
2-
Well, at least with 2.0, that's the way ServerName is
documented...
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
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
+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
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
12 matches
Mail list logo
