Opened at 2013-03-11T08:33:11Z
Last modified at 2016-01-31T23:54:57Z
#1928 assigned defect
web redirects should use relative URLs — at Initial Version
Reported by: | leif | Owned by: | davidsarah |
---|---|---|---|
Priority: | normal | Milestone: | soon |
Component: | code-frontend-web | Version: | 1.9.2 |
Keywords: | http redirect webapi | Cc: | tahoe-lafs.org@… |
Launchpad Bug: |
Description
Certain uses of the web interface result in unfollowable redirects.
This request to the web interface returns a redirect to a newly created directory, as a relative URL:
curl -v -F t=mkdir -F redirect_to_result=true http://localhost:3456/uri
< Location: uri/URI%3ADIR2%3Ajhjqp....
I think this is good. Unfortunately, this relative URL does not include a trailing slash, so when it is followed the response is another redirect, to append the slash. This second redirect is not relative. It begins with http://hostname:port/uri/URI.... where "hostname" is the host part of the value in the request's Host header and "port" is the configured web.port. Even if the request's Host header includes a port number, the web.port is used in the absolute URL constructed.
I think all redirects should use relative URLs, because according to https://en.wikipedia.org/wiki/HTTP_location "most popular web browsers tolerate the passing of a relative URL as the value for a Location header.[citation needed]".
If absolute URLs must be constructed for some reason, the port from the Host header should be used.
The motivation for this request is to make the web interface more usable on ports that are not the configured web.port, for example via SSH port forwarding or a Tor hidden service.
This also makes it easier to run tahoe as an unprivileged user while proxying port 80 to it.
If I'm not mistaken, currently, such a proxying configuration would require rewriting the absolute redirects in Tahoe's responses (perhaps with Apache's ProxyPassReverse? directive) to avoid having certain functions (like the 2nd redirect after creating a directory) fail.
By always using relative redirects, simple TCP proxies (like SSH port forwarding) can be accommodated and the web ui shouldn't need to think about port numbers in URLs at all.