[tahoe-lafs-trac-stream] [Tahoe-LAFS] #1901: WUI: the "Download!" button on the Welcome page leads to the file displayed in-browser instead of downloaded/saved

[Tahoe-LAFS]

#1901: WUI: the "Download!" button on the Welcome page leads to the file displayed
in-browser instead of downloaded/saved
---------------------------------+-----------------------------------------
     Reporter:  zooko            |      Owner:
         Type:  defect           |     Status:  new
     Priority:  normal           |  Milestone:  undecided
    Component:  code-frontend-   |    Version:  1.9.2
  web                            |   Keywords:  LeastAuthority.com wui easy
   Resolution:                   |
Launchpad Bug:                   |
---------------------------------+-----------------------------------------

Comment (by warner):

 User "lcstyle" on IRC noticed this same problem tonight, and might have
 time to hack on it. I suggested the following:

 * src/allmydata/web/root.py `Root.render_download_form()` (line 304)
 constructs the welcome page's download form
 * that form uses method="GET" and sends the browser to a URL like
 `/uri?uri=FILECAP&filename=FILENAME`
 * src/allmydata/web/root.py `URIHandler.render_GET()` (line 28) is
 responsible for handling that GET, and currently responds by issuing a 302
 Redirect to `/uri/FILECAP?filename=FILENAME`
 * we really want it to redirect to `/named/FILECAP/FILENAME?save=true`

 We don't want to change the redirect behavior for existing URLs, since
 it's documented to retrieve the contents (and *not* add the download-only
 Content-Disposition header). So I think we should make
 `render_download_form()` add a third queryarg (via an HTML hidden input
 field), "download=true". When `URIHandler.render_GET()` sees
 `download=true`, it should use the different redirect behavior. Otherwise
 it should do the old behavior.

 According to the docs, using `/uri/FILECAP?filename=FILENAME&save=true` is
 supposed to result in a download. I'm not sure if this could possibly get
 the filename right (which I think is why we added the
 `/named/FILECAP/FILENAME` form, so that browsers would see a "filename" in
 the place they expect it). We should test that and maybe update the docs
 (docs/frontends/webapi.rst, line 1048, "!Viewing/Downloading a File") to
 remove that claim.

--
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1901#comment:7>
Tahoe-LAFS <https://Tahoe-LAFS.org>
secure decentralized storage