[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:  assigned
     Priority:  normal             |  Milestone:  soon
    Component:  code-frontend-web  |    Version:  1.9.2
   Resolution:                     |   Keywords:  http redirect webapi
Launchpad Bug:                     |
-----------------------------------+----------------------------------

Old 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.

New 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.

--

Comment (by daira):

 #1861 seems to be in conflict with this ticket.

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