[whatwg] "Content-Disposition" property for <a> tags

[Eduard Pascual]

On Fri, Jul 30, 2010 at 12:36 PM, Dennis Joachimsthaler <dennis at efjot.de> wrote:
> Hello,
>
> I have an idea which would be very cool for HTML5.
>
> Having a Content-Disposition property on <a> tags which does the same as
> the HTTP Header.
> For example changing the file name of the file to be downloaded or rather
> have a image
> file download rather than it being shown in the browser directly.
>
> This would avoid constructs such as <a href="hi">Download</a> (Right click
> and click save
> target as... to download).
>
> It would also eliminate the need to handle such requests with a server
> side scripting engine to change the headers dynamically to enforce
> downloading
> of the content.
>
> HTML5 can already act on the http headers with the rel="noreferer" property.
>
> Please give me your opinion about this
>
> Thank you in advance!
>

I was just about to post asking for something in that line, but you
were faster than me ^^,

Let me complement the proposal with a use case:
http://stackoverflow.com/questions/3358209/triggering-a-file-download-without-any-server-request

Also, a few comments on the potential/alledged security implications
(based on the above use case):
  - This is already doable via plug-ins such as Flash. So barring this
feature may only improve security (if it improves at all) when Flash
and the like are disabled. This may even get counter-productive if
this feature becomes the one that convinces a user to enable Flash or
some other relatively unsafe plug-in.
  - Sites can already trigger downloads by round-tripping to the
server, so this is more a sort of convenience: the script could send
the data through a POST request and the server send it back with the
Content-disposition header. In general, this feature would help
removing some delay and improving reliability, but on some cases it'd
be a huge enabler:
      * Offline apps can't rely on a server. However, origin-based
restrictions on downloads could be applied to the app based on where
did the app come from.
      * Many free and 'newbie' hosts allow hosting html and some media
files (such as images and sound), but offer no server-side scripting
at all. Hence apps on such hosts have currently no standard mechanisms
to trigger a save dialog or any equivalent UI feature. In some cases,
these hosts may even forbid flash, thus making the task entirely
impossible.
  - The user will normally have the ultimate say on whether the file
is saved or not, and where on the file system will it be saved.
Actually, this is the reason why I wanted something like this instead
of using the Storage APIs: I want to give the user full control.

To top things up, note that "saving a file to disk" is always equally
or less dangerous than "letting the UA perform the default action for
a resource": on the most "evil" scenario, there would be at least one
further step of confirmation or user action before the saved data has
a chance to do anything (assuming it's in some executable form;
otherwise it will never "do" anything).

Dennis' proposal allows for more than my use-case (actually, my intent
was to propose adding something to data: urls rather than to <a>
elements, which may point anywhere); but I don't see any reason why
the link with such attribute would be more dangerous than without it.

Regards,
Eduard Pascual