http://www.safe4all.org/privatespace

Instead, they are redirected to

http://www.safe4all.org/www.safe4all.org/privatespace/

Which of course doesn't work.

Any suggestions?

When I don't use the trailing "/", and attempt a telnet:

    $ telnet www.safe4all.org 80
    ...
    GET /register HTTP/1.1

    HTTP/1.0 302 Found
    ...
    Location: http://safe4all.org:8000/register/

So, it's redirecting to port 8000 of "safe4all.org".  Check your SystemURL parameter from ACS Kernel.  Or maybe your Tcl init file.

Hope these stabs in the dark help...

I don't notice the problem in Safari, where I have a cookie with my login. I can go to anywhere I want.

I believe it was the same with Explorer, but when I logged out, and tried to log back in, I get that weird redirection error to

http://www.safe4all.org/register/www.safe4all.org/register/user-new?email=mylogin%40location%2ecom&persistent%5fcookie%5fp=1&return%5furl=%2f

So it doesn't seem to be a routing issue, right? If it was, it wouldn't work for all the static pages and for /news. And it wouldn't work for me, with my cookie to log in.

Could this be a bug in the new permission code? Don, perhaps something introduced in 4.6.2? I might have used the upgrade script to 4.6.2 on accident...

Actually, I'm embarrased to say... I think it's strange that it works at all. It's listening on port 8000, but the router doesn't seem to be forwarding the ports to 8000 from 80, only from 8000. I don't remember how I set it up.

What you need to get the server redirect correct is the following addition to your nsd.tcl file:

# If you want your web domain name to be www.example.com
# set up the following in you nsd.tcl file:
# ns_section "ns/server/${servername}/module/nssock"
# ns_param        port          8000 ;# Actual private port 
# ns_param        hostname      www.example.com ;# Internet Hostname
# ns_param        address       192.168.1.2 ;# Actual private ip
# ns_param        location      http://www.example.com ;# Protocol://Hostname
# The location parameter is essential for automatic redirects and for proper
# use of [ns_conn location], otherwise redirect would go to 
# http://www.example.com:8000

So what does your telnet session to /register return now?

Well, using Netscape 7.0 on Win XP, if I go to /register, it correctly redirects me to /register/, so seems like it works. The redirection page also looks correct.

IE.5+ on MacOS has a bug where it doesn't redirect.  It just waits indefinitely. You might check to see if that's the case for the other one. Check it against a standard 404 redirect on another site.

I get the same problem using IE6.0 on Win2k. I also experienced the same problem on one of my demo sites, but it appeared to be a result of installing a package I'm working on. When I deleted the package the redirection problem went away! I'm currently going through the code of my package to see if there's anything weird there. The demo site is using OACS4.6 and that's the only place I've seen with the problem. I'll keep you posted...

Michael

I don't have the time to fix it now.

Take a look at this thread. Your symptoms seem similar to mine. I think the problem occurs when your server is on a nonstandard port and the browser is MSIE.

The patch I supplied fixed my problem.

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" } {

It's great that you've got your OpenACS site going. I see Arsdigita and Redhat mentioned, not OpenACS though...

/Randy

Index: utilities-procs.tcl
===================================================================
RCS file: /var/cvs/safe4all/packages/acs-tcl/tcl/utilities-procs.tcl,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 utilities-procs.tcl
--- utilities-procs.tcl 1 Jun 2004 17:45:40 -0000      1.1.1.1
+++ utilities-procs.tcl 4 Jun 2004 04:31:11 -0000
@@ -2685,6 +2685,10 @@
        }
    }

+    # HACK TO WORK WITH NON-STANDARD PORTS, as per
+    # http://openacs.org/forums/message-view?message_id=84289
+    return "$proto://$hostname"
+
    if { ![empty_string_p $port] && ![string equal $port $default_port($proto)] } {
        return "$proto://$hostname:$port"
    } else {