[whatwg] a rel=attachment

[Darin Fisher]

On Thu, Jul 14, 2011 at 12:36 PM, Glenn Maynard <glenn at zewt.org> wrote:

> 2011/7/14 Ian Fette (イアンフェッティ) <ifette at google.com>
>
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> >
>
> This has been raised a couple times:
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-July/027455.html
>
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-April/031190.html(thread
> was derailed partway through)
>
> I've wanted this several times and I'm strongly in favor of it.
>

Yes, it seems very useful.



>
> After mulling this over with some application developers who are trying to
> > use this functionality, it seems like adding a "rel" attribute to the <a>
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case. <a rel=attachment href=blah.pdf> would indicate that the browser
> >
>
> This isn't enough; the filename needs to be overridable as well, as it is
> with Content-Disposition.  My recommendation has been:
>
> <a href=image.jpg download>
> <a href=f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.jpg download=picture.jpg>
>
> where the first is equivalent to Content-Disposition: attachment, and the
> second is equivalent to Content-Disposition: attachment;
> filename=picture.jpg.
>
>
This is an interesting variation!  I like that it addresses the issue of
providing a name for the download.  Using the term "download" here is also
nice.

I know that there is also a proposal to add a FileSaver API.  I like that as
well, _but_ it is very nice to be able to simply decorate an anchor tag.  In
many cases, that will be a lot simpler for developers than using JavaScript
to construct a FileSaver.  I think it makes sense to implement both.

On the other thread, Michal Zalewski raised a concern about giving
client-side JS the power to name files.  It looks like that discussion did
not conclude, but I will note that even without the proposal here to name
the download, an attacker could still have control over the downloaded
filename.  They could either manufacture a file using the FileSystem API,
and then get a filesystem: URL to that file, or they could simply use a
server to produce an URL with a C-D header of their choosing.  It seems like
we are well past the point of trying to limit a web page authors ability to
influence the downloaded filename.  Fortunately, however, user agents can
protect the user from potentially harmful downloads.  Chrome for instance
asks the user to confirm the download of a EXE file before we ever write a
file to the filesystem with a .exe extension.

-Darin