#2531 closed defect (worksforme)
Reconstruction of absolute URL fails in a proxy setup
Reported by: | Owned by: | Jonas Borgström | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | general | Version: | 0.9.3 |
Severity: | major | Keywords: | Federal Judge Limits Access to Cellphone Data washingtonpost.com/wp-dyn/content/article/2008/09/11/AR2008091103292.html |
Cc: | jberry@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
(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'
Attachments (0)
Change History (18)
comment:1 by , 19 years ago
comment:2 by , 19 years ago
Milestone: | 0.9.3 → 0.9.4 |
---|
This would mean that the form submission doesn't contain the file upload itself… which I've never encountered or heard of myself.
comment:3 by , 19 years ago
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 ;-)
comment:4 by , 19 years ago
Cc: | added |
---|---|
Component: | ticket system → general |
Summary: | adding attachment to ticket produces attachment KeyError → adding attachment to ticket or wiki produces attachment KeyError |
Version: | 0.9.2 → 0.9.3 |
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/
comment:5 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
okay, I resolved the issue for me personally, by using mod_python instead of tracd/mod_proxy…
still strange, though…
comment:7 by , 19 years ago
Cc: | removed |
---|---|
Milestone: | 0.9.4 |
Resolution: | → worksforme |
Status: | reopened → closed |
comment:8 by , 19 years ago
Description: | modified (diff) |
---|---|
Milestone: | → 0.9.5 |
Priority: | normal → high |
Resolution: | worksforme |
Status: | closed → reopened |
Summary: | adding attachment to ticket or wiki produces attachment KeyError → Reconstruction of absolute URL fails in a proxy setup |
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.
comment:9 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
comment:10 by , 19 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
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.
comment:12 by , 19 years ago
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…!
comment:13 by , 19 years ago
Cc: | added |
---|
comment:14 by , 19 years ago
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)
comment:15 by , 18 years ago
Resolution: | → worksforme |
---|---|
Status: | reopened → closed |
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.
comment:16 by , 16 years ago
Keywords: | Federal Judge Limits Access to Cellphone Data washingtonpost.com/wp-dyn/content/article/2008/09/11/AR2008091103292.html added; Candidates Promise National-Service Initiatives washingtonpost.com/wp-dyn/content/article/2008/09/11/AR2008091103788.html removed |
---|
Federal Judge Limits Access to Cellphone Data washingtonpost.com/wp-dyn/content/article/2008/09/11/AR2008091103292.html
comment:17 by , 16 years ago
Mm. No idea how to feed BadContent to catch the above spam. wp-dyn maybe? Marking as spam doesn't seem to be a good either as there are only common words. Ideas welcomed.
hmm.. here it works fine… perhaps it's our setup? but what else could factor in?