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

New Issue

tahoe-lafs · 2009-11-01T06:34:45Z

davidsarah commented

2009-11-01 06:34:45 +00:00

Typical behaviour of web browsers for a retrieved over HTTPS, 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:

(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 ).

Typical behaviour of web browsers for a retrieved over HTTPS, 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> ).

tahoe-lafs added the

labels 2009-11-01 06:34:45 +00:00

tahoe-lafs added this to the undecided milestone 2009-11-01 06:34:45 +00:00

tahoe-lafs changed title from ~~Support forcing download using "Content-Disposition: attachment" in WUItre~~ to Support forcing download using "Content-Disposition: attachment" in WUI

2009-11-01 06:37:41 +00:00

tahoe-lafs added

code-frontend-web

and removed

unknown

labels 2009-11-01 06:38:28 +00:00

davidsarah commented

2010-01-22 21:08:50 +00:00

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.

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.

tahoe-lafs changed title from ~~Support forcing download using "Content-Disposition: attachment" in WUI~~ to Put file download links ('?save=true') in WUI directory listings

2010-01-22 21:08:50 +00:00

tahoe-lafs modified the milestone from undecided to 1.7.0

2010-02-01 19:50:39 +00:00

davidsarah commented

2010-05-02 13:49:48 +00:00

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

tahoe-lafs modified the milestone from 1.7.0 to 1.8.0

2010-05-17 02:19:40 +00:00

tahoe-lafs modified the milestone from 1.8.0 to soon

2010-08-08 05:32:34 +00:00

tahoe-lafs modified the milestone from soon to 1.11.0

2012-08-27 18:12:56 +00:00

davidsarah commented

2012-08-27 18:16:56 +00:00

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.

Replying to [davidsarah](/tahoe-lafs/trac-2024-07-25/issues/827#issuecomment-73391): > 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 commented

2012-08-27 18:40:11 +00:00

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 commented

2012-08-27 18:44:39 +00:00

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:

Pure no-JS-required WUI/WAPI
Pure bytes data port -- you should never ever point a web browser at this port! Use the web content port instead.
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.
New shiny JS-powered WUI/WAPI

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 commented

2012-08-27 19:01:28 +00:00

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:73397 :

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.

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:73397](/tahoe-lafs/trac-2024-07-25/issues/827#issuecomment-73397) : * 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 commented

2012-08-27 19:09:12 +00:00

Multiple ports ticket filed as #1798.

tahoe-lafs modified the milestone from 1.11.0 to 1.12.0

2013-08-13 23:00:06 +00:00

warner commented

2016-03-22 05:02:25 +00:00

Milestone renamed

warner modified the milestone from 1.12.0 to 1.13.0

2016-03-22 05:02:25 +00:00

warner commented

2016-06-28 18:17:14 +00:00