Ability to override SCRIPT_NAME from base_url

[oetiker@…]

I am using mod_rewrite to hide the fcgi trac script ... this works fine, except that trac uses absolte urls in its generated content ... so the name of the fcgi script will be exposed all the same ... with this patch I can set the TRAC_BASE_URL environment variable to tell trac what base URL it should be using.

--- temp/trac/trac-0.9/trac/web/cgi_frontend.py 2005-10-31 19:37:51.000000000 +0100
+++ pack/trac-0.9/lib/python2.3/site-packages/trac/web/cgi_frontend.py  2005-11-02 23:30:52.393286000 +0100
@@ -49,6 +49,10 @@
         self.args = self._getFieldStorage()
 
         self.cgi_location = self.__environ.get('SCRIPT_NAME')
+
+        if 'TRAC_BASE_URL' in os.environ:
+            self.cgi_location = os.environ['TRAC_BASE_URL'];
+
         self.idx_location = self.cgi_location
 
         self.path_info = self.__environ.get('PATH_INFO', '')

[mgood]

Instead of mod_rewrite, use a ScriptAlias command to point to the fcgi script and the CGI SCRIPT_NAME variable will be set appropriately.

To run Trac at the root URL:

ScriptAlias / /usr/share/trac/cgi-bin/trac.fcgi

[jo@…]

But if one uses RewriteEngine to hide user names in suexec configurations, ScriptAlias does not work. It breaks the suexec mechansim. In such a situation BASE_URL would be a good idea.

[sid]

Patch attached, so should be reviewed.

[cmlenz]

1. the patch is outdated (would need to be updated for 0.10)
2. this functionality is available by use of the base_url option in trac.ini

[tobi@…]

base_url in trac.ini does not allow to override what SCRIPT_NAME returns ... which is necessary when working without ScriptAlias? (see above). The following patch adds the necessary functionallity for trac 0.10:

--- trac/web/api.py.orig        2006-09-21 20:32:16.000000000 +0200
+++ trac/web/api.py     2006-10-22 14:00:07.000000000 +0200
@@ -223,7 +223,15 @@
                                'has not logged in using HTTP authentication')
     scheme = property(fget=lambda self: self.environ['wsgi.url_scheme'],
                       doc='The scheme of the request URL')
-    base_path = property(fget=lambda self: self.environ.get('SCRIPT_NAME', ''),
+
+    def _get_base_url(self):
+       from urlparse import urlparse
+       if self.base_url:
+               return urlparse(self.base_url.encode('latin-1'))[2]
+       else:
+               return self.environ.get('SCRIPT_NAME')
+
+    base_path = property(fget=_get_base_url,
                          doc='The root path of the application')
     server_name = property(fget=lambda self: self.environ['SERVER_NAME'],
                            doc='Name of the server')
                                                                                                                                                                                              

[dom@…]

I would like this patch to make it in - it is as far as I can see the only way to make nice URLs with fcgi and mod_rewrite. I am currently manually patching to achieve this aim.

[cboos]

Could someone familiar with fcgi review this?

[thatch]

A slightly related ticket is #2418, which strangely shows up in searches while this one initially didn't.

I run Trac under mod_python and thus can't have this issue (modpython_frontend bails if TRAC_URI_ROOT and base_url don't match), however if this issue still needs fixing I came up with a patch with tests that doesn't reimport urlparse.

[mgood]

Replying to cboos:

Could someone familiar with fcgi review this?

Yeah, I'll do it.

[mgood]

This has been fixed with r4718:4719 and r4720.

This uses Apache's SCRIPT_URL variable which is specifically intended for reconstructing the logical URL when rewriting has been used, so I think this a cleaner solution.

[James Teh <jamie@…>]

If you are using Apache mod_rewrite and the script path is still exposed, be aware that the SCRIPT_URL variable is not set by mod_rewrite if the RewriteEngine on directive is used in .htaccess or directory context. SCRIPT_URL is only set if RewriteEngine on is used in the server or VirtualHost context. This is an extremely frustrating issue in mod_rewrite. I thought this worth noting here to hopefully save others some agony in the future. :)

[James Teh <jamie@…>]

Err... it'd be nice if I didn't change all the properties by mistake. I think I just found a Firefox bug. :) Sorry people. I can't change the milestone back to 0.10.4, which is what it should be.