Edgewall Software
Modify

Opened 9 years ago

Closed 6 years ago

Last modified 4 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
Priority: normal Milestone:
Component: general Version: 0.11rc1
Severity: normal Keywords: fastcgi, lighttpd
Cc: shot@…, alexander@…, gustavo@…
Release Notes:
API 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@… 7 years ago.
Patch provided by thatch in #trac on FreeNode?

Download all attachments as: .zip

Change History (19)

comment:1 Changed 9 years ago by stephen_purcell@…

  • Keywords fastcgi lighttpd added
  • Summary changed from Relative paths broken when project at root URL under lighttpd with fastcgi to Relative paths broken when project at root URI under lighttpd with fastcgi

comment:2 Changed 9 years ago by 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?

comment:3 Changed 9 years ago by 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.

comment:4 Changed 9 years ago by 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 ;)

comment:5 Changed 9 years ago by 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

comment:6 Changed 8 years ago by 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.

comment:7 Changed 8 years ago by anonymous

  • Cc shot@… added

comment:8 Changed 8 years ago by anonymous

  • Cc shot@… added; shot@… removed

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

comment:9 Changed 8 years ago by mgood

  • Resolution set to wontfix
  • Status changed from new to closed

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.

Changed 7 years ago by lindevel@…

Patch provided by thatch in #trac on FreeNode?

comment:10 Changed 7 years ago by lindevel gmx net

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

comment:11 Changed 7 years ago by jeremy@…

  • Resolution wontfix deleted
  • Severity changed from normal to blocker
  • Status changed from closed to reopened

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 follow-up: Changed 7 years ago by eblot

  • Resolution set to wontfix
  • Severity changed from blocker to normal
  • Status changed from reopened to closed

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.

comment:13 in reply to: ↑ 12 Changed 7 years ago by anonymous

  • Resolution wontfix deleted
  • Severity changed from normal to blocker
  • Status changed from closed to reopened
  • Version changed from 0.9 to 0.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 Changed 6 years ago by rcsheets@…

  • Version changed from 0.11b1 to 0.11rc1

This issue is still present in 0.11rc1.

comment:15 Changed 6 years ago by thatch

  • Severity changed from blocker to normal

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

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

comment:17 Changed 6 years ago by rblank

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 Changed 4 years ago by 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)

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed The owner will remain jonas.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from jonas to the specified user.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.