I can’t think of any sane reason to reverse proxy Trac when you can serve it up under Apache over SSL, except when you can’t. I backported the latest version of Trac, 0.10.2, to Debian Sarge. The process was quite painful, but the result won’t run under mod_python without some additional backporting, though ultimately that may have been easier.

To my dismay, Apache 2.0.55’s mod_proxy doesn’t seem to like Trac’s 303 response to HTTP POST form actions. Firefox explains it cannot connect to localhost after a POST operation. Of course, the changes are still saved by Trac, but it’s still disturbing.

I also discovered that at least as of Trac 0.10.2, you cannot successfully use plain HTTP authentication. Only digest authentication works, but you cannot reverse proxy that as far as I can tell, leading to my installation of the Account Manager Plugin egg for Trac 0.10.2.

Running Trac as straight CGI is probably the only solution I have not yet tried as it will be far slower than using tracd.

Below, a response from tracd after a form login POST operation.

HTTP/1.0 303 See Other 
Server: tracd/0.10.2 Python/2.3.5 
Date: Fri, 22 Dec 2006 19:35:29 GMT 
Location: http://example.com/vrl 
Content-Type: text/plain 
Pragma: no-cache 
Cache-control: no-cache 
Expires: Fri, 01 Jan 1999 00:00:00 GMT 
Set-Cookie: trac_auth=a5bb401454f1085ac0c185a5c3b240f7; Path=/vrl; 
Set-Cookie: trac_session=0afebd71a6c275ef0d78cf97; expires=Fri, 22-Dec-2006 19:35:29 GMT; Path=/vrl; 
	
Redirecting...