1. IE 6 exhibits the following buggy behavior. When it accesses a nonstandard port (i.e. not port 80) and then switches to SSL, it doesn't change the port in the Location header. That is, it should redirect from http://blah:8000 to httpS://blah:8443, but instead it redirects to httpS://blah:8000. I haven't tried to confirm this.
2. CR Oldham patched util_current_location to take care of this. If both the following are true:
   • Server is running on a port other than 80
   • Client is MSIE
   then, the location will be built from scratch as follows:

   $proto://$host:$port
   

   • where $proto is determined from the driver being used. nssock=http, nsssl,nsopenssl=https
   • $host is determined from the Header supplied by the browser
   • $port is determined from the config file.
   It's acutally built with this regsub.

   regsub -nocase {(.*):.*} $host_from_header "$proto://\\1:$port" location_from_host_header
   

   What does this regsub do? It takes the $host_from_header, strips off the port at the end, and sticks it in between $proto and $port. It's important to note that it expects to find the colon in $host_from_header. That is, it expects a header like "abc.org:8000". If there's no colon, the regsub fails. This is important.
3. This works fine except in the following case. When your server is on a nonstandard port, but the client thinks it's on port 80. This is Jade's situation (due to port forwarding) and mine (due to using AOLserver's virtual hosting). In this case, both conditions above will be true, but the client is requesting a location on port 80. Even though the server is running on a nonstandard port, the client doesn't know it. So the Host header will look like "abc.org". Look! No colon. Now the regsub fails and util_current_location returns a location like "abc.org" instead of "http://abc.org". This gets sent to ns_returnredirect which sees that it doesn't have a "http" at the front, so it slaps on the current location from the Host header, and you get the duplicate-looking URLs.
4. How I would fix it. The MSIE bug only occurs in SSL, right? So, I propose that if the driver being used is nssock, then we don't do any URL mangling, but instead just use the Host from the HTTP headers like we used to. If we're using an SSL driver, we'll continue to fix the IE bug.

RCS file: /cvsroot/openacs-4/packages/acs-tcl/tcl/utilities-procs.tcl,v
retrieving revision 1.19.2.19
diff -u -b -B -r1.19.2.19 utilities-procs.tcl
--- utilities-procs.tcl 7 Jun 2003 01:47:33 -0000   1.19.2.19
+++ utilities-procs.tcl 3 Sep 2003 03:50:41 -0000
@@ -2542,12 +2542,8 @@
    # Is this server running on a non-standard port?
    set nonstandard 0
    if { [ad_conn driver] == "nssock" } {
-       if { [ns_config -int "ns/server/[ns_info server]/module/nssock" Port 80\
] != 80 } {
-      set nonstandard 1
-      set port [ns_config -int "ns/server/[ns_info server]/module/nssock" Port\
 80]
-      set proto http
-       }
-
+       # MSIE bug only occurs in SSL. Don't mess with nssock connections
+       set nonstandard 0
    }

    if { [ad_conn driver] == "nsssl" || [ad_conn driver] == "nsssle" } {

isn't the parameter ForceHostP thought to determine this behaviour? Atleast it used to work like this in ACS 3.4.x.
Setting ForceHostP=0 meant that the server woudn't touch the client's header.

I'm running my first productive site on OpenACS 5.0 now with an external url of http://intranet.dnsalias.com:80/ and an internal URL of http://192.168.0.1:30018/, and coming from the "outside" I get redirected to http://intranet.dnsalias.com:30018/.

Bests,
Frank

mailto:frank.bergmann_at_project-open_doc_com
http://www.project-open.com/