Re: [PATCH] UseCanonicalName (1.3/2.x)

2003-11-13 Thread Jeff Trawick
Jim Jagielski wrote:

Brad Nicholes wrote:

Also, this exposes a bug, I think, in 2.0/2.1.
parsed_uri.port is valid iff parsed_uri.port_str != NULL.
Currently, we are testing just to see if parsed_uri.port
itself isn't 0.
What you are saying then is that without testing parsed_uri.port_str,
there is no way of knowing if port 0 could actually be a valid port or
if parsed_uri.port contains garbage that just happens to look like a
port.  The former depends on whether port 0 can actually be a valid port
and the latter depends on how the parsed_uri structure is initialized.


From what I can see (prelim look into the URI parsing) it is
possible for port to be garbage if port_str == NULL. Exactly
what kind of garbage is undefined... it could be 0 for some
and *real* garbage for others... The check for port!=0 doesn't
suffice to ensure that the value used for port is *valid*.
Note that a garbage value of port that is non-zero would
be used as valid in 2.x right now...
any hints on how to reproduce this problem?

is there some bad or unhelpful behavior in apr_uri_parse() that should be 
changed?  (i.e., don't let port be non-zero if port_str is NULL)

it looks to me that apr_uri_parse() can set port_str to  in some cases where 
there is no explicit port specified and the port integer is set to the default 
port of the scheme:

   uptr-port_str = apr_pstrmemdup(p, s, uri - s);
if (uri != s) {
port = strtol(uptr-port_str, endstr, 10);
uptr-port = port;
if (*endstr == '\0') {
goto deal_with_path;
}
/* Invalid characters after ':' found */
return APR_EGENERAL;
}
uptr-port = apr_uri_port_of_scheme(uptr-scheme);
goto deal_with_path;
in this case, I don't see that checking port_str is going to do the right 
thing...

Maybe I'm barking up the wrong tree, but I get the feeling that maybe the real 
problem is that apr_uri_parse() doesn't return with port and port_str set to 
consistent values, and that this must be fixed anyway, and once it is fixed 
then it doesn't matter whether or not other code checks port or port_str.




Re: [PATCH] UseCanonicalName (1.3/2.x)

2003-11-13 Thread Jim Jagielski
Jeff Trawick wrote:
 
 is there some bad or unhelpful behavior in apr_uri_parse() that should be 
 changed?  (i.e., don't let port be non-zero if port_str is NULL)

Well, it's *documented* that port is only valid if port_str != NULL.
I see no reason why we need to change the code, when the method
of using a valid 'port' is documented and correctly used in
other locations (such as mod_proxy). The actual URI code works
as advertised; we weren't just *using* it as advertised.

 
 it looks to me that apr_uri_parse() can set port_str to  in some cases where 
 there is no explicit port specified and the port integer is set to the default 
 port of the scheme:
 

Which is fine... If there is no explicit port, then setting port
to the scheme default port is safe (and expected). 

-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson


[PATCH] UseCanonicalName (1.3/2.x)

2003-11-12 Thread Jim Jagielski
Could we try this... This does change, slightly, On
under 1.3 to be aware of the connection port number
and to use that in preference over the default
port.
Also, this exposes a bug, I think, in 2.0/2.1.
parsed_uri.port is valid iff parsed_uri.port_str != NULL.
Currently, we are testing just to see if parsed_uri.port
itself isn't 0.
This patch is for 1.3.29...

Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.326
diff -u -r1.326 http_core.c
--- src/main/http_core.c19 Oct 2003 13:20:57 -  1.326
+++ src/main/http_core.c12 Nov 2003 19:07:12 -
@@ -826,16 +826,27 @@
 API_EXPORT(unsigned) ap_get_server_port(const request_rec *r)
 {
 unsigned port;
+unsigned cport = ntohs(r-connection-local_addr.sin_port);
 core_dir_config *d =
   (core_dir_config *)ap_get_module_config(r-per_dir_config, 
core_module);

-port = r-server-port ? r-server-port : ap_default_port(r);
-
 if (d-use_canonical_name == USE_CANONICAL_NAME_OFF
-   || d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
-return r-hostname ? ntohs(r-connection-local_addr.sin_port)
-  : port;
+|| d-use_canonical_name == USE_CANONICAL_NAME_DNS) {
+
+/* 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).
+ */
+port = r-parsed_uri.port_str ? r-parsed_uri.port :
+  cport ? cport :
+r-server-port ? r-server-port :
+  ap_default_port(r);
+} else { /* d-use_canonical_name == USE_CANONICAL_NAME_ON */
+port = r-server-port ? r-server-port :
+  cport ? cport :
+ap_default_port(r);
 }
+
 /* default */
 return port;
 }


Re: [PATCH] UseCanonicalName (1.3/2.x)

2003-11-12 Thread Brad Nicholes


Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

 Jim Jagielski [EMAIL PROTECTED] Wednesday, November 12, 2003
12:13:10 PM 
Could we try this... This does change, slightly, On
under 1.3 to be aware of the connection port number
and to use that in preference over the default
port.

+1

Also, this exposes a bug, I think, in 2.0/2.1.
parsed_uri.port is valid iff parsed_uri.port_str != NULL.
Currently, we are testing just to see if parsed_uri.port
itself isn't 0.

What you are saying then is that without testing parsed_uri.port_str,
there is no way of knowing if port 0 could actually be a valid port or
if parsed_uri.port contains garbage that just happens to look like a
port.  The former depends on whether port 0 can actually be a valid port
and the latter depends on how the parsed_uri structure is initialized.

Brad




Re: [PATCH] UseCanonicalName (1.3/2.x)

2003-11-12 Thread Jim Jagielski
Brad Nicholes wrote:
 
 Also, this exposes a bug, I think, in 2.0/2.1.
 parsed_uri.port is valid iff parsed_uri.port_str != NULL.
 Currently, we are testing just to see if parsed_uri.port
 itself isn't 0.
 
 What you are saying then is that without testing parsed_uri.port_str,
 there is no way of knowing if port 0 could actually be a valid port or
 if parsed_uri.port contains garbage that just happens to look like a
 port.  The former depends on whether port 0 can actually be a valid port
 and the latter depends on how the parsed_uri structure is initialized.
 

From what I can see (prelim look into the URI parsing) it is
possible for port to be garbage if port_str == NULL. Exactly
what kind of garbage is undefined... it could be 0 for some
and *real* garbage for others... The check for port!=0 doesn't
suffice to ensure that the value used for port is *valid*.
Note that a garbage value of port that is non-zero would
be used as valid in 2.x right now...

mod_proxy, by the way, gets this right and checks port_str before
using port.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]   http://www.jaguNET.com/
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson


Re: [PATCH] UseCanonicalName (1.3/2.x)

2003-11-12 Thread Brad Nicholes
+1 checking for port_str

Brad

Brad Nicholes
Senior Software Engineer
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

 Jim Jagielski [EMAIL PROTECTED] Wednesday, November 12, 2003
1:50:37 PM 
Brad Nicholes wrote:
 
 Also, this exposes a bug, I think, in 2.0/2.1.
 parsed_uri.port is valid iff parsed_uri.port_str != NULL.
 Currently, we are testing just to see if parsed_uri.port
 itself isn't 0.
 
 What you are saying then is that without testing
parsed_uri.port_str,
 there is no way of knowing if port 0 could actually be a valid port
or
 if parsed_uri.port contains garbage that just happens to look like a
 port.  The former depends on whether port 0 can actually be a valid
port
 and the latter depends on how the parsed_uri structure is
initialized.
 

From what I can see (prelim look into the URI parsing) it is
possible for port to be garbage if port_str == NULL. Exactly
what kind of garbage is undefined... it could be 0 for some
and *real* garbage for others... The check for port!=0 doesn't
suffice to ensure that the value used for port is *valid*.
Note that a garbage value of port that is non-zero would
be used as valid in 2.x right now...

mod_proxy, by the way, gets this right and checks port_str before
using port.
-- 
===
   Jim Jagielski   [|]   [EMAIL PROTECTED]   [|]  
http://www.jaguNET.com/ 
  A society that will trade a little liberty for a little order
 will lose both and deserve neither - T.Jefferson