Re: Proposed anchor target attribute _download

On 1/3/13 10:14 PM, Charles McCathie Nevile wrote:
> An author is expected to know whether I would prefer to download a
> resource or simply open it normally. This strikes me as unlikely.

Note that authors can already do this with the Content-Disposition 
header for http:// requests.

In fact Gecko's implementation of @download just maps it onto a 
Content-Disposition value on the network load.  There is a distinction 
which is that Content-Disposition is under the control of the server 
hosting the data while @download is under the control of the linking 
page; see more on this below.

I believe the main intent of @download was to expand the capabilities 
offered by Content-Disposition to URI schemes that don't have headers. 
Specifically, data: and blob URIs were the primary use cases.

> In short, it seems unclear that Ian thought carefully about the use
> cases before writing a specification of the attribute.

I think the reasoning was that if it makes sense to allow this for http 
(via Content-Disposition), it should probably also be allowed in other 
cases.

In particular, this allows web sites to offer "download" links for 
script-generated data, which is something people often want.

> This still leaves the download algorithm providing some security ideas,
> and the attribute suggesting a filename when it is saved - something
> that the HTTP Content-Disposition also does if I recall correctly.

Indeed.

Note that in Gecko the security issues are mitigated by only allowing 
@download to affect same-origin requests, for cases in which there is 
origin information associated with the network load (obviously for data: 
and blob the origin is just that of the linking page, so @download works 
on those).

Chrome seems to place fewer restrictions on @download, but it's not 
clear to us that their approach is safe enough.

I agree that the spec's treatment of security issues is ... 
insufficient.  Though note that the spec's processing model leaves a 
fair bit of weasel room for a UA to ignore @download whenever it wants to.

> In summary, the attribute proposing a name seems an unnecessary addition
> to the web platform for such a trivial functionality.

Being able to provide a sane filename for data: and blob URIs is a 
_very_ common author request.  Addressing that is one of the main goals 
here.

-Boris

Received on Friday, 4 January 2013 03:40:09 UTC