tahoe-lafs/trac

paste-in-a-URI form on the welcome page vs. proxies #461

New issue

Closed

opened 2008-06-12 23:04:27 +00:00 by warner · 8 comments

warner commented

2008-06-12 23:04:27 +00:00

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.

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.

warner added the

labels 2008-06-12 23:04:27 +00:00

warner added this to the undecided milestone 2008-06-12 23:04:27 +00:00

zandr commented

2008-06-18 00:20:10 +00:00

Owner

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.

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.

warner commented

2008-06-18 02:48:54 +00:00

Author

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.

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.

warner self-assigned this 2008-06-18 02:48:54 +00:00

warner commented

2009-04-08 02:19:36 +00:00

Author

This isn't going to get fixed for 1.4.0 . Maybe 1.4.1 .

warner added this to the 1.4.1 milestone 2009-04-08 02:19:36 +00:00

warner commented

2009-11-30 21:51:16 +00:00

Author

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.

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.

zooko modified the milestone from 1.6.0 to eventually

2010-01-26 15:39:55 +00:00

daira modified the milestone from eventually to 1.7.0

2010-02-11 03:40:12 +00:00

zooko modified the milestone from 1.7.0 to eventually

2010-06-16 02:19:19 +00:00

zooko changed title from ~~webapi: some relative links are borked~~ to paste-in-a-URI form on the welcome page vs. proxies

2010-09-18 17:53:42 +00:00

zooko commented

2010-09-18 17:56:24 +00:00

I just went to the http://pubgrid.tahoe-lafs.org/ proxy and put this cap into the form labeled "Download a file
Tahoe-URI to download:" -- URI:CHK:4gjkekcwy43cd7g5bwglw3rh7a:t5rfar4m3pfj2ifhbmtfk2hzqaqrc3qzm6lpupqcnuibs55zh5tq:3:10:141159 . It successfully downloaded the file. Brian: does that mean this ticket can be closed?

I just went to the <http://pubgrid.tahoe-lafs.org/> proxy and put this cap into the form labeled "Download a file Tahoe-URI to download:" -- URI:CHK:4gjkekcwy43cd7g5bwglw3rh7a:t5rfar4m3pfj2ifhbmtfk2hzqaqrc3qzm6lpupqcnuibs55zh5tq:3:10:141159 . It successfully downloaded the file. Brian: does that mean this ticket can be closed?

warner commented

2010-09-21 22:13:56 +00:00

Author

To close this ticket, I think we need to look at each URL (specifically each tag) on the main pages (welcome page, directory WUI page, and the More-Info page) and make sure that all of them point to the right places (relative links, and certainly not to the non-proxied "real" hostname). I think the "Download a file" box was the most important case, but the ticket is about checking all of them.

To close this ticket, I think we need to look at each URL (specifically each <a> tag) on the main pages (welcome page, directory WUI page, and the More-Info page) and make sure that all of them point to the right places (relative links, and certainly not to the non-proxied "real" hostname). I think the "Download a file" box was the most important case, but the ticket is about checking all of them.

Lcstyle commented

2014-09-26 21:47:08 +00:00

Owner

I just looked at:

the Welcome Page
Directory WUI page
more info page

None of them have any references to wrong hostname and are all relative.

I just looked at: the Welcome Page Directory WUI page more info page <several other pages> None of them have any references to wrong hostname and are all relative.