Forum OpenACS Q&A: aolserver 4 virtual hosting problem

Collapse
Posted by Vinod Kurup on
I'm using the virtual hosting that is built into AOLServer and I'm seeing a weird problem.

My sites work fine when I'm browsing with Camino (Mozilla) or Lynx, but when I use IE6/Win, all my form submissions or redirects have my hostname inserted in the middle of the url.

So, when I register on the front page, the registration works, but then I get redirected to http://example.com/register/example.com

or if I add a new photo-album, the album is added and then i get redirected to http://example.com/photo/example.com/photo/album?album_id=495

It only happens on IE6, although I haven't tested other browsers extensively yet. I know not too many people are using VH on AS4 yet, but i'm just wondering if anyone knew where I should start looking...

Thanks

Collapse
Posted by Jade Rubick on
Vinod, what version of OpenACS is your site? Have you done some recent upgrades?

Have you tried telneting to the page, and seeing if you get the same redirect?

I had a similar problem that occured because my upgrade hadn't gone through correctly, even though I thought it had. I posted on this somewhere, and also submitted a bug.

Not sure if it's the same problem, but it might be worth checking into.

I don't have virtual hosting, and I'm not using Aolserver 4, however.

Collapse
Posted by Vinod Kurup on
Thanks Jade. I'm using CVS from the openacs-4-6 branch updated yesterday.

I think I figured out the problem. ad_returnredirect checks if the client is MSIE and if the server is running on a nonstandard port (i.e. not port 80). If both of those conditions exist, then it creates the redirect_url in a different way than usual, thus working around an IE bug.

With VH set up, the virtual server (or backend) runs on a nonstandard port, but the client never knows about it. The client only sees the port of the frontend server and all the proxying is done within aolserver. ad_returnredirect only checks which port the backend server is running on. It sees port 8001, so it tries to workaround the IE bug, but this causes the regsub not to work properly, thus returning a redirect_url that looks like "example.com/blah/blah". Since there's no 'http://' at the front, ns_returnredirect adds "http://example.com" to the front and boom! 404

So, if the frontend server is on port 80, then ad_returnredirect shouldn't go ahead with its IE kludge.

The patch looks like this:


RCS file: /var/lib/cvs/kurup/packages/acs-tcl/tcl/utilities-procs.tcl,v
retrieving revision 1.1.1.1
diff -u -b -B -r1.1.1.1 utilities-procs.tcl
--- utilities-procs.tcl 9 Jun 2003 03:07:40 -0000       1.1.1.1
+++ utilities-procs.tcl 16 Jun 2003 19:50:31 -0000
@@ -2542,12 +2542,23 @@
    # 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 } {
+       # if we are using virtualhosting, the client will only know about the
+       # frontend (or master) port, so we need to use the correct port
+       set frontend_port [ns_config -int "ns/module/nssock" Port]
+       set backend_port \
+          [ns_config -int "ns/server/[ns_info server]/module/nssock" Port]
+
+       if { [string is integer -strict $frontend_port] } {
+          # we're using virtual hosting
+          set port $frontend_port
+       } else {
+          set port $backend_port
+       }
+
+       if { $port != 80 } {
           set nonstandard 1
-          set port [ns_config -int "ns/server/[ns_info server]/module/nssock" Port 80]
           set proto http
        }
-
    }

    if { [ad_conn driver] == "nsssl" || [ad_conn driver] == "nsssle" } {
I'm not familiar with SSL/OpenSSL, so I'm not sure if the same changes need to be made for those sections.