Hello, I eventually try to install in ACS4.2 an old module (ACS4.0) which claim to resolve the famous problem of adding additional domain names that point to the same IP as the main domain name of your server and to map these domain names to site nodes (i.e. directories) of your web site.

This piece of software was written by Mark Dettinger of AD. Basically one new table is created, some admin pages are added and the main request processor is modified.

After some basic tests it seems to work. GREAT

Should the permission on the subsite not allow public read, the system would not link the user to the login page and an error is displayed on the browser. Also each subsite could only be linked to one domain name.

Should you need more information let me know. Michel

My experience is that it is basically working, but there is still something wrong. Here are the details:

1. I must run my site off of port 8080 because my ISP blocks port 80 on incoming requests.
2. Using site-map, I create a subfolder off of / called "OakmontReunion".
3. I use the host-node-map (/admin/host-node-map) to map "oakmontreunion.dyndns.org" to have a root url of "/OakmontReunion/"
4. I try to visit the "http://oakmontreunion.dyndns.org:8080/register" URL and get redirected to the wrong place. Using "wget" to show the sequence of redirects clearly indicates the problem:

   wget http://oakmontreunion.dyndns.org:8080/register
   --16:01:25--  http://oakmontreunion.dyndns.org:8080/register
              => `register'
   Connecting to oakmontreunion.dyndns.org:8080... connected!
   HTTP request sent, awaiting response... 302 Found
   Location: http://oakmontreunion.dyndns.org:8080/OakmontReunion/register/ [following]
   --16:01:32--  http://oakmontreunion.dyndns.org:8080/OakmontReunion/register/
              => `index.html'
   Connecting to oakmontreunion.dyndns.org:8080... connected!
   HTTP request sent, awaiting response... 302 Found
   Location: http://oakmontreunion.dyndns.org/register/ [following]
   --16:01:32--  http://oakmontreunion.dyndns.org/register/
              => `index.html'
   Connecting to oakmontreunion.dyndns.org:80... ^C
   

   It looks like the request processor is loosing the port information in one of it's redirects. I'll try and locate the problem, but if any of the core team gets there first I would be quite gratefull. Jeff.

Here's a patch that appears to fix the problem.
<p>
I added a routine called &quot;ad_proc&quot; that will return the port portion of the request (including the leading &quot;:&quot;) and then modified the second case
in &quot;rp_filter&quot;.
<pre>
--- openacs-4/packages/acs-tcl/tcl/request-processor-procs.tcl  Thu Oct 18 14:49:45 2001
+++ openacs4/packages/acs-tcl/tcl/request-processor-procs.tcl  Wed Nov  7 17:50:19 2001
@@ -5,7 +5,7 @@

    @author Jon Salz (jsalz@arsdigita.com)
    @date 15 May 2000
-    @cvs-id $Id: request-processor-procs.tcl,v 1.6 2001/10/18 21:49:45 donb Exp $
+    @cvs-id $Id: request-processor-procs.tcl,v 1.1.1.1 2001/10/30 06:06:55 nsadmin Exp $
}

#####
@@ -367,10 +367,10 @@
        }
        if {[ad_secure_conn_p]} {
            # it's a secure connection.
-            ad_returnredirect https://[ad_host]$url
+            ad_returnredirect https://[ad_host][ad_port]$url
            return "filter_return"
        } else {
-            ad_returnredirect http://[ad_host]$url
+            ad_returnredirect http://[ad_host][ad_port]$url
            return "filter_return"
        }
    }
@@ -1024,6 +1024,18 @@
        return $host
    } else {
        return "unknown host"
+    }
+}
+
+ad_proc ad_port {} {
+    Returns the port as it was typed in the browser,
+    provided forcehostp is set to 0.
+} {
+    set host_and_port [ns_set iget [ns_conn headers] Host]
+    if { [regexp {^([^:]+):([0-9]+)} $host_and_port match host port] } {
+      return ":$port"
+    } else {
+      return ""
    }
}

</pre>

It seems strange that the request processor would discard the :port part of the Host header. The :port is important. Obviously for a webserver a different port could be a completely different server. It is probably too late to do much with the current behavior, they should have called the ad_conn variable 'hostname', not host. Then it might have been more obvious what data the var contains. One allowable would be lowercasing the data, in case the browser doesn't do that.