Relative paths broken when project at root URI under lighttpd with fastcgi

[stephen_purcell@…]

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

[elvstone@…]

I have the same problem. LigHTTPD-1.4.8/Trac-0.9.2 under FastCGI, with Trac under root URI. Anyone got an idea?

[elvstone@…]

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.

[elvstone@…]

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 ;)

[anonymous]

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

[shot@…]

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.

[anonymous]

I knew there is better solution :) BTW, thanks for a great job you're doing

[Matthew Good]

This is a bug in Lighttpd that occurs when the URL mapped to a FastCGI app ends with "/": ​http://trac.lighttpd.net/trac/ticket/729

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.

[lindevel@…]

Patch provided by thatch in #trac on FreeNode

[lindevel gmx net]

PS: TRAC_LIGHTTPD_ROOT_WORKAROUND should be set to "/" if you want to run Trac in the root of the server.

[jeremy@…]

I applied the patch at ​http://trac.edgewall.org/attachment/ticket/2418/trac_lighttpd_root_workaround.patch 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.

[Emmanuel Blot]

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.

[anonymous]

Replying to eblot:

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.

[rcsheets@…]

This issue is still present in 0.11rc1.

[Tim Hatch]

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()

[Remy Blank]

According to this ticket:

​http://redmine.lighttpd.net/issues/show/729

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.

[anton]

For your information:

at ​http://redmine.lighttpd.net/issues/show/729 they write that this issue is fixed

in the lighttpd version 1.4.23 (as of today the version is 1.4.26)