Re: Request for feedback - UseCanonicalPort
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 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. However, they are times when you want to say, I don't care what port you connected to, or what port you have in the url, I am contructing all redirects (or whatever) based on the port of my choosing. Isn't this what UseCanonicalName On does with servername? No matter what host header you send, no matter how you got to this server, Apache will use ServverName. I just need to be able to have it not care about the ServerName, but use a selected port. -- Brian Akins Senior Systems Engineer CNN Internet Technologies
Re: Request for feedback - UseCanonicalPort
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 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. 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: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 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.
Re: Request for feedback - UseCanonicalPort
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 environments. Though I suspect that I've missed some discussion here - I can thing of at least 2 cases where a UseCanonicalPort separate from the name would be goodness. Or alternatively some more sublte client-fall-through-filter-and-add/replace-values. But +1 on not overloading Name further and separate into Port. Dw
Re: Request for feedback - UseCanonicalPort
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 Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 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 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. 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: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 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.
Re: Request for feedback - UseCanonicalPort
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 PM, Brad Nicholes wrote: 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 Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 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 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. 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: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 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.
Re: Request for feedback - UseCanonicalPort
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 was added to netware/os.c by redefining ap_default_port() to ap_os_default_port(). These patches resolve the issue of where does the port come from. Neither of them address the issue of when or how the port value should be used. So I believe that the example you gave of: 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: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 unless the client appends ':80' to the Host header :/ would still be broken. In fact searching back through the mailing list archieve for [EMAIL PROTECTED], Matthieu Estrade's issue with ap_get_server_port() sounded similar to the example that you gave, but it is what prompted the 2.1 patch and the backport proposal. (http://marc.theaimsgroup.com/?l=apache-httpd-devm=103798747720589w=2 ) Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 11:32:30 AM 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 PM, Brad Nicholes wrote: 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 Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 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 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. 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
Re: Request for feedback - UseCanonicalPort
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 implementation of least astonishment. On May 12, 2004, at 1:59 PM, Brad Nicholes wrote: 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 was added to netware/os.c by redefining ap_default_port() to ap_os_default_port(). These patches resolve the issue of where does the port come from. Neither of them address the issue of when or how the port value should be used. So I believe that the example you gave of: 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: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 unless the client appends ':80' to the Host header :/ would still be broken. In fact searching back through the mailing list archieve for [EMAIL PROTECTED], Matthieu Estrade's issue with ap_get_server_port() sounded similar to the example that you gave, but it is what prompted the 2.1 patch and the backport proposal. (http://marc.theaimsgroup.com/?l=apache-httpd-devm=103798747720589w=2 ) Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 11:32:30 AM 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 PM, Brad Nicholes wrote: 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 Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 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 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. 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
Re: Request for feedback - UseCanonicalPort
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- server-port 3- ap_default_port() USE_CANONICAL_NAME_ON 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. Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 12:25:55 PM 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 implementation of least astonishment. On May 12, 2004, at 1:59 PM, Brad Nicholes wrote: 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 was added to netware/os.c by redefining ap_default_port() to ap_os_default_port(). These patches resolve the issue of where does the port come from. Neither of them address the issue of when or how the port value should be used. So I believe that the example you gave of: 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: LB: www.foo.com:80 Apache: foo1.foo.com:8000 Apache should send www.foo.com:80, but instead it'll send www.foo.com:8000 unless the client appends ':80' to the Host header :/ would still be broken. In fact searching back through the mailing list archieve for [EMAIL PROTECTED], Matthieu Estrade's issue with ap_get_server_port() sounded similar to the example that you gave, but it is what prompted the 2.1 patch and the backport proposal. (http://marc.theaimsgroup.com/?l=apache-httpd-devm=103798747720589w=2 ) Brad Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] Wednesday, May 12, 2004 11:32:30 AM 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 PM, Brad Nicholes wrote: 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 Brad Nicholes Senior Software Engineer Novell, Inc., the leading provider of Net business solutions http://www.novell.com [EMAIL PROTECTED] 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
Re: Request for feedback - UseCanonicalPort
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 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 VirtualHost 10.0.0.1 ServerName foo Port 80 /VirtualHost 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: USE_CANONICAL_NAME_OFF || USE_CANONICAL_NAME_DNS 1- parsed_uri.port 2- server-port 3- ap_default_port() USE_CANONICAL_NAME_ON 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.
Re: Request for feedback - UseCanonicalPort
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)...
Re: Request for feedback - UseCanonicalPort
+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)...
Request for feedback - UseCanonicalPort
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)...
