Put file download links ('?save=true') in WUI directory listings

[davidsarah]

Typical behaviour of web browsers for a retrieved over HTTP[S], is to decide based on its inferred MIME type whether to display it, pass it to some plugin/helper app, or treat it as a download (either pass it to a download manager or prompt the user to save it locally). The inferred MIME type is arrived at by rules that no-one understands; the HTTP spec says that the HTTP Content-Type takes precedence, but browsers deliberately violate that in some cases, and the result can even vary nondeterministically depending on network delays.

Sometimes it's useful to override this behaviour and force the browser to treat the file as a download, regardless of its inferred MIME type. This can be done using the Content-Disposition HTTP header, e.g. "Content-Disposition: attachment; filename=suggested_name".

(Well, not actually force, but strongly hint. I think all the common browsers now implement this; IE has had some bugs ​http://support.microsoft.com/kb/279667 but I think they are all pre-IE6.)

Content-Disposition is specified in:

• ​http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html#sec19.5.1
• ​http://tools.ietf.org/html/draft-reschke-rfc2183-in-http-00

(The "very serious security considerations" mentioned in ​http://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.5 are scaremongering. A server can't do anything with Content-Disposition: attachment that can't also be done via the MIME type.)

To close this ticket,

• add an optional parameter to the webapi that will force a download.
• modify Tahoe directory listings to include 'download' and 'view' links.

Note that if the most prominant link for a non-directory file was the download link, that would allow the WUI to be used from a browser (with some care on the part of users) without necessarily being vulnerable to the same-origin attacks described in #615. Users would only be vulnerable to these attacks if they click the view link, or if they view the downloaded local files in a browser that treats all file URLs as same-origin (or has some other related bug such as ​http://www.mozilla.org/security/announce/2009/mfsa2009-30.html ).

[davidsarah]

The facility to download using Content-Disposition: attachment already exists, using the save=true parameter. It is even documented in source:docs/frontends/webapi.txt . I was confused partly by seeing the undocumented @@named feature used by the file info page, which downloads the file as text/plain (treated by browsers as "guess the type").

However, there isn't any way to access the file download URI from the WUI other than by manually adding the save=true parameter, which makes this feature undiscoverable except by reading technical docs.

[davidsarah]

If #1029 were implemented, it would make sense for child entries that are directories to have a 'download as archive' link.

[davidsarah]

Replying to davidsarah:

If #1029 were implemented, it would make sense for child entries that are directories to have a 'download as archive' link.

The scope of this ticket for 1.11 is just to add the download link for files, probably as an icon next to the filename.

[zooko]

See also #277 where I wish for an alternate design for the WUI where every link in LAFS has a page in the WUI. That page would be the place where a Save-As and a Display would go, perhaps.

[zooko]

Brian suggested a good idea: a separate port for "pure bytes, unmolested by the LAFS layer -- what you put in is what you get at" and for "content, such as should be displayed in a web browser". Fetching a resource (e.g. with a file cap) from the latter port might result in content that wrapped in a Secure Ecmascript prefix, for example, which attempts to nullify the ability of Javascript within the content to do bad things once it is displayed in a browser.

I propose that we have separate ports for at least these uses:

1. Pure no-JS-required WUI/WAPI
2. Pure bytes data port -- you should never ever point a web browser at this port! Use the web content port instead.
3. Content for display--the content might be manipulated, such as by prepending a Secure Ecmascript prelude, or other attempts to confine the content when your browser runs it.
4. New shiny JS-powered WUI/WAPI

[davidsarah]

Please stay on topic for this ticket! A separate ticket should be filed for the multiple-port idea, or use #615 for general discussion of WUI same-origin and sandboxing issues.

Comment that should really be on #1797, except that it's addressing comment:14 :

• Note that HTML5 sandbox does not in any way require JS. Nor does it stop single-page JS webapps served from Tahoe from working, if allow-scripts is set in the sandbox tag. Multi-page JS webapps can also work if they do not rely on same-origin information sharing, although we might need to handle .css and .js filetypes differently because the browser will be expecting them to be served raw, not framed.

[davidsarah]

Multiple ports ticket filed as #1798.

[warner]

Milestone renamed

[warner]

renaming milestone

[exarkun]

Moving open issues out of closed milestones.

[meejah]

Ticket retargeted after milestone closed