[tahoe-lafs-trac-stream] [tahoe-lafs] #1928: web redirects should use relative URLs

[tahoe-lafs]

#1928: web redirects should use relative URLs
---------------------+----------------------------
 Reporter:  leif     |          Owner:  davidsarah
     Type:  defect   |         Status:  new
 Priority:  normal   |      Milestone:  undecided
Component:  unknown  |        Version:  1.9.2
 Keywords:           |  Launchpad Bug:
---------------------+----------------------------
 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.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1928>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage