- From: Alexey Proskuryakov <ap@webkit.org>
- Date: Fri, 22 Jul 2011 13:27:36 -0700
> On Tue, 19 Jul 2011, Alexey Proskuryakov wrote: >> >> What meaning will this attribute have on a platform that simply doesn't >> expose the notion of a file? > > None, presumably the same as "Content-Disposition: attachment" in the same > case. > > >> I think that this attribute could be quite confusing, and it will likely >> become more confusing with time, as more platforms arise that have >> creative ways of presenting data to users. > > Could you elaborate on what confusion you are expecting here? Having rel=attachment and download be named so differently implies that the functionality is different. For example, I'm sure that many people will waste time trying to see what they can do with @download on an iPhone that they couldn't do before with Content-Disposition. > On Tue, 19 Jul 2011, Alexey Proskuryakov wrote: >> >> The fact that hosting implies a certain degree of trust is also built >> into client software. For example, if you download an executable file on >> Mac OS X, then the system warns you about it on first launch, and tells >> you where it was downloaded from, not where a link to the download was. > > Which URL is given there of course depends on what URL the browser decides > to put there. It could be the page's URL. For reference, this is how the warning looks: <http://nypop.com/~ap/webkit/quarantine.png>. A browser can certainly find a way to put an arbitrary original URL here, but the behavior is not limited to browsers. Any application can use the download API, and non-browser applications will not necessarily have the notion of referencing page. Having different data depending on whether you download directly from a browser or using a download manager is of course no good. That said, as long as we don't need to honor a file extension provided in @download when it doesn't match Content-Type, it may not matter very much if a page gets the chance to modify the base part of the name. - WBR, Alexey Proskuryakov
Received on Friday, 22 July 2011 13:27:36 UTC