Opened 11 years ago
Closed 9 years ago
Last modified 7 years ago
#2418 closed defect (wontfix)
Relative paths broken when project at root URI under lighttpd with fastcgi
Description
I'm using Trac 0.9 on Debian 'unstable', and lighttpd 1.4.8.
Unlike the lighttpd examples given on the Trac wiki, my trac instance runs at the root URI of a dedicated domain. When I hit a URI such as '/timeline' on my trac site, all the relative links are prefixed '/timeline', so I have nav item links such as '/timeline/timeline' and '/timeline/browser'.
Is this a miscommunication of SCRIPT_PATH between lighttpd and the fastcgi handler?
The relevant lighttpd config snippet follows:
$HTTP["host"] =~ "^mysite\.com(:\d+)?$" { # Setup an alias for the static resources alias.url = ("/chrome/common" => "/usr/share/trac/htdocs") $HTTP["url"] !~ "^/chrome/common" { fastcgi.server = ( "/" => ( "trac" => ( "socket" => "/tmp/mysite-trac-fastcgi.socket", "min-procs" => 2, "max-procs" => 2, "idle-timeout" => 300, "bin-path" => "/usr/share/trac/cgi-bin/trac.fcgi", "check-local" => "disable", "bin-environment" => ( "TRAC_ENV" => "/home/mysite/trac" ) ) ) ) } }
Attachments (1)
Change History (19)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
comment:3 Changed 11 years ago by
Oh I forgot to say; I'm only seeing this problem when browsing with IE (6.x) strangely enough, with Firefox (1.5) all works fine.
comment:4 Changed 11 years ago by
I really don't understand why the GET / request from Firefox gets rewritten like this:
GET /cgi-bin/trac.fcgi HTTP/1.1 Host: dev.dose.se User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; sv-SE; rv:1.8) Gecko/20051111 Firefox/1.5 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: sv,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive
while the request from IE will not:
GET / HTTP/1.1 Accept: */* Accept-Language: sv Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Host: dev.dose.se Connection: Keep-Alive
but I solved (or worked around?) the problem by adding a redirection directive like:
url.redirect = ("^/$" => "/cgi-bin/trac.fcgi")
right after my
fastcgi.server = ("/" => ... etc ) directive.
If anyone with more wisdom could explain why I'm getting different results like this with IE/Firefox, that would be great ;)
comment:5 Changed 11 years ago by
I got that problem fixed by adding couple lines to fcgi_frontend.py
def _handler((_req): req = CGIRequest(_req.params, _req.stdin, _req.stdout) # next two lines fix the problem req.path_info = req.cgi_location + req.path_info req.cgi_location = '/'
I'm pretty sure there is better way but I had no time to dig deeper
comment:6 Changed 11 years ago by
The abovementioned
fcgi_frontend.py hack works, but it would be best if we could simply set
TracUriRoot via
TRAC_URI_ROOT (in the lighttpd’s conf file) and it worked properly.
comment:7 Changed 11 years ago by
comment:8 Changed 11 years ago by
I knew there is better solution :) BTW, thanks for a great job you're doing
comment:9 Changed 11 years ago by
This is a bug in Lighttpd that occurs when the URL mapped to a FastCGI app ends with "/":
For now you can work around this by removing the "/" from the end of the URL mapping. There's nothing Trac can do to fix this, so I'm going to close this ticket. You can follow the ticket on Lighttpd if you want to see when it's fixed.
Changed 10 years ago by
comment:10 Changed 10 years ago by
PS: TRAC_LIGHTTPD_ROOT_WORKAROUND should be set to "/" if you want to run Trac in the root of the server.
comment:11 Changed 9 years ago by
I applied the patch at and it worked great.
Anyway to get this in the main distribution so I don't have to do it each time?
I understand that applying hacks for particular servers is not desired, but you do have individual settings for mod_python, so I don't see how this is that different.
This bug blocked me from using trac in a production setting at the root of my server until I got it fixed.
comment:12 follow-up: 13 Changed 9 years ago by
comment:13 Changed 9 years ago by
If you encounter the issue with Trac 0.9, please first upgrade to a recent release, then open a new ticket if the error still exists.
At the time I reopened the ticket, I was running the latest version of .10. I just upgraded to .11b1 and still have the issue.
I just realized I'd reported the wrong version in the ticket filing last time I opened up. Sorry about that.
comment:14 Changed 9 years ago by
This issue is still present in 0.11rc1.
comment:15 Changed 9 years ago by
Another workaround suggested by coderanger and mitsuhiko for running trac at
/ is to mangle
SCRIPT_NAME in the fcgi file
#! /usr/bin/python from flup.server.fcgi import WSGIServer from trac.web.main import dispatch_request def application(environ, start_request): environ['PATH_INFO'] = environ['SCRIPT_NAME'] + environ['PATH_INFO'] environ['SCRIPT_NAME'] = '' return dispatch_request(environ, start_request) if __name__ == '__main__': WSGIServer(application).run()
comment:16 Changed 9 years ago by
comment:17 Changed 9 years ago by
According to this ticket:
the issue is fixed in Lighttpd 1.5.0, and the author is working on a solution for 1.4.x. So this is definitely not an issue in Trac.
comment:18 Changed 7 years ago by
For your information:
at they write that this issue is fixed
in the lighttpd version 1.4.23 (as of today the version is 1.4.26)
I have the same problem. LigHTTPD-1.4.8/Trac-0.9.2 under FastCGI, with Trac under root URI. Anyone got an idea?