Reconstruction of absolute URL fails in a proxy setup

[tom@…]

(ticket changed direction somewhat since original submission, see below)

checked that user running trac (www) has write access to the attchments folder.

Traceback (most recent call last):
  File "/usr/local/lib/python2.4/site-packages/trac/web/standalone.py", line 303, in _do_trac_req
    dispatch_request(path_info, req, env)
  File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/local/lib/python2.4/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/local/lib/python2.4/site-packages/trac/attachment.py", line 265, in process_request
    self._do_save(req, attachment)
  File "/usr/local/lib/python2.4/site-packages/trac/attachment.py", line 295, in _do_save
    upload = req.args['attachment']
  File "/usr/local/lib/python2.4/cgi.py", line 559, in __getitem__
    raise KeyError, key
KeyError: 'attachment'

[tom@…]

hmm.. here it works fine... perhaps it's our setup? but what else could factor in?

[cmlenz]

This would mean that the form submission doesn't contain the file upload itself… which I've never encountered or heard of myself.

[tom@…]

Well, we haven't modified any templates, just the footer lines etc. in the .ini file. I have meanwhile been able to reproduce the error on a different machine, as well.

It's quite troubling for us, really.

The two things in common with those setups is that I've installed trac 0.9.2 via the freebsd ports collection.

I don't know anything about trac's inner workings yet, could you please elaborate on your above comment? I'm really anxious to get this fixed and will do whatever I can to help get this resolved. Let's not drop the ball on this one, if possible ;-)

[tom@…]

updating to 0.9.3 brought no relief :-( The error also occurs when attempting to add attachments to a wiki page.

I did find out, though, that the error does not occur, when I access trac directly (I'm running tracd on port 8000 and have apache to a proxypass)

perhaps apache is somehow the culprit? afterall, the form in question does contain the input field attachment.

Here's my VirtualHost? entry, perhaps that will help:

    ProxyPass / http://intern:8000/
    ProxyPassReverse / http://intern:8000/

[tom@…]

okay, I resolved the issue for me personally, by using mod_python instead of tracd/mod_proxy...

still strange, though...

[mgood]

This should be worksforme

[cmlenz]

This issue has come up a number of times again, and I think I finally know the culprit now: we shouldn't be trying to extract the X-Forwarded-Host header and use that for reconstructing the absolute URL. The proxy (e.g. mod_proxy_http) actually expects the host name of the original machine, and will replace that with it's own host name.

We'll include the simple fix for this in 0.9.5.

[cmlenz]

Was fixed in [3119] and [3120].

[Norbert.Klamann@…]

I tried to apply these fixes on a 0.9.3 with no avail. I can see and navigate the site but whenever I try a change the system tries to open a non-https - URL (this URL is visible in then browser) and this leads to a 400. I use mod_python, FWIW. I reopen the thing.

[kL]

I'm using 0.9.5 and trac puts it's private URL in RSS feeds.

[jberry@…]

Just to reiterate the findings of kL, the tracd setup that was working for me in 0.9.4 (tracd running behind mod_proxy reverse proxy from apache 2.2.2) is now hosed. RSS feeds now reference content using the localhost url by which mod_proxy addresses tracd, rather than using the external url.

Maybe tracd should have a parameter that specifies the external url by which it is visible? I don't want to run mod_proxy_html...!

[kevin@…]

After TextDrive? updated to 0.9.5. today, my Trac installlation now suffers from this exact issue. On form submissions, I am redirected to localhost, rather than the proper, proxied URL (which, interestingly enough, worked pre-0.9.5)

[cmlenz]

You'll need to specify the base_url option in TracIni to fix the absolute URLs in the RSS feeds when running behind a proxy.