[tahoe-dev] [tahoe-lafs] #827: Support forcing download using "Content-Disposition: attachment" in WUItre
tahoe-lafs
trac at allmydata.org
Sat Oct 31 23:34:45 PDT 2009
#827: Support forcing download using "Content-Disposition: attachment" in WUItre
--------------------------------+-------------------------------------------
Reporter: davidsarah | Owner: nobody
Type: defect | Status: new
Priority: major | Milestone: undecided
Component: unknown | Version: 1.5.0
Keywords: security usability | Launchpad_bug:
--------------------------------+-------------------------------------------
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 ).
--
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/827>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid
More information about the tahoe-dev
mailing list