[whatwg] Priority between <a download> and content-disposition

[Gordon P. Hemsley]

On Tue, May 7, 2013 at 10:18 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/7/13 5:54 PM, Gordon P. Hemsley wrote:
>>
>> A @download attribute with a value would override both factors, like so:
>> (1) Download it.
>> (2) "A.txt"
>
> Why?
>
> You say this as if it were obvious, but it's not obvious to me at all...
> What's the reasoning that makes this the desirable behavior?

It's not clear to me which of the two factors you take issue with.

Here's what the spec says:

"The download attribute, if present, indicates that the author intends
the hyperlink to be used for downloading a resource. The attribute may
have a value; the value, if any, specifies the default file name that
the author recommends for use in labeling the resource in a local file
system."

I interpret that first sentence to mean that the file should be
downloaded (disposition type = attachment) rather than displayed
(disposition type = inline). The second sentence very clearly suggests
that "A.txt" would be the filename presented to the user by default in
the save dialog.

>> I don't see what the security concerns might be: There is no
>> difference here than what is already available
>
> There is if you allow cross-origin @download.
>
> There is if you allow untrusted markup on your server and don't sanitize
> away @download (should it be sanitized away?  Unclear).

I'm still not seeing what the problem is. All this does is make the
browser treat the link as if the user followed it and then went File >
Save Page As....

What are the security concerns, cross-origin or otherwise?

>> AFAICT, there are no content
>> sniffing or cross-domain issues at play.
>
> But there are; see above.

Well, what I should have said is, there is no content sniffing beyond
what is already done for regular page saves. (The UI can show the MIME
type or format of the file in the download box, as it would for any
file it doesn't handle natively.)

>> results when saving a file; they don't do any file extension vs. file
>> format checking.
>
> Uh... that depends on exactly how you save and your OS.  Browsers commonly
> do file extension vs MIME type checking on Windows.  Behavior on other OSes
> varies, and varies across browsers.
>
> -Boris

Ah, I admit, I'm a bit biased towards Mac in that regard. It's been a
while since I used Windows. But I'd be surprised to find out that the
browser (Firefox, in the case I have in mind) changes the extension in
the suggested filename (e.g. "example.php" for an HTML file) on
Windows but not on Mac, and I would argue that that perhaps should not
be the case.

--
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/