Opened at 2008-06-12T23:04:27Z
Last modified at 2014-09-26T23:46:27Z
#461 closed defect
paste-in-a-URI form on the welcome page vs. proxies — at Version 8
| Reported by: | warner | Owned by: | warner |
|---|---|---|---|
| Priority: | major | Milestone: | eventually |
| Component: | code-frontend-web | Version: | 1.1.0 |
| Keywords: | wui test proxy | Cc: | |
| Launchpad Bug: |
Description (last modified by zooko)
Apparently the "paste-in-a-URI form" in the welcome page might not work through proxies.
(original ticket is below)
At least the "Return To Welcome Page" link (from a directory page) is broken, it contains way too many ../ components.
Zandr has noticed other links that are broken too, probably absolute links (perhaps starting with /uri) that ought to be relative ones.
Change History (8)
comment:1 Changed at 2008-06-18T00:20:10Z by zandr
comment:2 Changed at 2008-06-18T02:48:54Z by warner
- Milestone changed from undecided to 1.1.1
- Owner set to warner
- Status changed from new to assigned
I think I've fixed this for everything except the .css files that are referenced by the <head> element. I only have test coverage on about 10% of this.
So, still todo:
- make the .css files referenced with a relative link
- add to test_GET_DIRURL and have it check all links
- add a test that fetches /uri/PARENTURI/CHILDNAME/ and makes sure the links are correct there too. These links should have one extra ../ compared to the /uri/PARENTURI/ form.
comment:3 Changed at 2009-04-08T02:19:36Z by warner
- Milestone changed from 1.4.0 to 1.4.1
This isn't going to get fixed for 1.4.0 . Maybe 1.4.1 .
comment:4 Changed at 2009-11-30T21:51:16Z by warner
I see no instances of url.here in the web/ code. There are a handful of URL.fromString(when_done) places, which is basically supposed to absolute-ize the relative URL that the client gives to the server in the when_done= argument.. I don't know how those should interact with a frontend proxy.
There's one other place where URL.fromString is used and then manipulated: in web/root.py (URIHandler.render_GET), which is the code that turns a GET /uri?uri=FILECAP into GET /uri/FILECAP, which provides support for the paste-in-a-URI form on the welcome page. That code removes the uri= argument, keeps any other arguments, and redirects to the proper /uri/FILECAP url. This might not work with a proxy.. I don't know how to construct the proper relative URL that keeps the right arguments and gets rid of the rest, but it's probably possible.
comment:5 Changed at 2010-01-26T15:39:55Z by zooko
- Milestone changed from 1.6.0 to eventually
comment:6 Changed at 2010-02-11T03:40:12Z by davidsarah
- Keywords wui test proxy added
- Milestone changed from eventually to 1.7.0
comment:7 Changed at 2010-06-16T02:19:19Z by zooko
- Milestone changed from 1.7.0 to eventually
comment:8 Changed at 2010-09-18T17:53:42Z by zooko
- Description modified (diff)
- Summary changed from webapi: some relative links are borked to paste-in-a-URI form on the welcome page vs. proxies
Indeed, the links in the 'Filename' column of the table begin with /uri, and therefore don't get proxied correctly.
Also, the form submit buttons are referencing the actual hostname:port of the box behind the proxy. Brian is standing next to me and telling me that he should refrain from using url.here and just use relative URLs.