Edgewall Software
Modify

Opened 18 years ago

Closed 15 years ago

Last modified 14 years ago

#2418 closed defect (wontfix)

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

Reported by: stephen_purcell@… Owned by: Jonas Borgström
Priority: normal Milestone:
Component: general Version: 0.11rc1
Severity: normal Keywords: fastcgi, lighttpd
Cc: shot@…, alexander@…, gustavo@… Branch:
Release Notes:
API Changes:
Internal Changes:

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)

trac_lighttpd_root_workaround.patch (582 bytes ) - added by lindevel@… 17 years ago.
Patch provided by thatch in #trac on FreeNode

Download all attachments as: .zip

Change History (19)

comment:1 by stephen_purcell@…, 18 years ago

Keywords: fastcgi lighttpd added
Summary: Relative paths broken when project at root URL under lighttpd with fastcgiRelative paths broken when project at root URI under lighttpd with fastcgi

comment:2 by elvstone@…, 18 years ago

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

comment:3 by elvstone@…, 18 years ago

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 by elvstone@…, 18 years ago

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 by anonymous, 18 years ago

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 by shot@…, 18 years ago

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 by anonymous, 18 years ago

Cc: shot@… added

comment:8 by anonymous, 18 years ago

Cc: shot@… added; shot@… removed

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

comment:9 by Matthew Good, 18 years ago

Resolution: wontfix
Status: newclosed

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.

by lindevel@…, 17 years ago

Patch provided by thatch in #trac on FreeNode

comment:10 by lindevel gmx net, 17 years ago

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

comment:11 by jeremy@…, 16 years ago

Resolution: wontfix
Severity: normalblocker
Status: closedreopened

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.

comment:12 by Emmanuel Blot, 16 years ago

Resolution: wontfix
Severity: blockernormal
Status: reopenedclosed

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.

in reply to:  12 comment:13 by anonymous, 16 years ago

Resolution: wontfix
Severity: normalblocker
Status: closedreopened
Version: 0.90.11b1

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.

comment:14 by rcsheets@…, 16 years ago

Version: 0.11b10.11rc1

This issue is still present in 0.11rc1.

comment:15 by Tim Hatch, 16 years ago

Severity: blockernormal

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 by gustavo@…, 16 years ago

Cc: shot@… alexander@… gustavo@… added; shot@… removed

comment:17 by Remy Blank, 15 years ago

Resolution: wontfix
Status: reopenedclosed

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.

comment:18 by anton, 14 years ago

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)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.