Submit button POST generates a 303 which uses hostname instead of base_url

[tlyons@…]

We have trac (0.11b) setup on a machine behind an apache reverse proxy. I'll call the machines trac and rp. The trac machine is called trac.domain.net (internal hostname) and the rp has trac.domain.com pointing at its external IP. When a client is (for example) setting Preferences and clicks the submit button, the sequence is:

1. Webclient sends POST to public hostname (rp), which sends POST to trac using internal hostname.

2. trac generates a 303 to the rp, but the 303 contains the internal hostname instead of the one defined in trac.ini base_url.

3. Webclient sends next GET to internal hostname instead of to public hostname.

This seems to happen repeatably on the Preferences screen, and with irregularity on the regular Wiki parts, so I think it's more than just the Preferences submit button.

If I'm needed interactively, I also hang out in IRC on freenode in #trac as cannonball, 7AM-4PM PST8PDT.

This can be fixed at the reverse proxy by setting the ProxyPassReverse on the rp, but the issue is that trac should 303 to the base_url instead of to the hostname. The fix on the rp is to detect all instances of the internal hostname and rewrite it to generic path, at which point the browser will substitute the public hostname in the appropriate places. Here's how:

ProxyPassReverse /project http://trac.domain.net/project

[Christian Boos]

If you really want that Trac uses the base_url setting for the redirects, then you should set use_base_url_for_redirect = true in TracIni#trac-section.

But I'm not sure if that's appropriate here, as you will then be redirected to the base_url (trac.domain.com) in all cases, even when accessing trac from .domain.net.

If that's OK for you, then fine, otherwise I don't see how you could avoid the ProxyPassReverse setting.

[tlyons@…]

As explained in the post, there is already an option which provides this functionality, I had just missed the option in the documentation. Additionally, we were still getting complaints from a couple people that the issue was still popping up, so the ProxyPassReverse isn't fixing the problem, which leaves as the only solution to use the use_base_url_for_redirect setting.