file URLs built incorrectly (perhaps mod_proxy interaction?)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| loggerhead |
New
|
Undecided
|
Unassigned | ||
Bug Description
With Loggerhead 1.10, browsing to a path or rev within a branch can fail, apparently because loggerhead tries build complete URLs (with host and port information) while running behind Apache mod_proxy.
If the reproduction recipe below isn't enough to point to the source of the problem, let me know; I can try to reproduce it with my own httpd setup. This recipe just demonstrates the problem using savannah.gnu.org, as described in https:/
To reproduce, go to:
http://
Then click on "gnash", which should successfully bring you here:
http://
Then click on "README", which fails because it tries this URL:
http://
(The other files there have similar problems.)
To see that the problem is not about file-vs-directory, go back to the original URL:
http://
Then click on "gnujump":
http://
Then click on "trunk":
http://
Then try any of the subdirectories that appear at the top of the listing there, such as "doc" or "src":
http://
http://
The problem happens for them too. (Also, I wonder why clicking on "trunk" while in "gnujump" extended the URL by "trunk/files" instead of just by "trunk", but I'm not sure that's related to this problem.)
By the way, the same problem exists for revisions. This is the "35" next to the subdir "doc":
http://
| Michael Hudson-Doyle (mwhudson) wrote | #1 |
| Karl Fogel (kfogel) wrote | #2 |
| Sylvain Beucler (beuc) wrote | #3 |
| Ian Brandt (ian-ianbrandt) wrote | #4 |
| Michael Hudson-Doyle (mwhudson) wrote | #5 |
Well, it's demonstrably possible to do this right, because we do it on launchpad :)
Questions that spring to mind:
1) how are you starting loggerhead?
2) is paste.deploy installed? if so, what version?