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

[Gordon P. Hemsley]

On Wed, May 8, 2013 at 12:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 5/8/13 12:15 PM, Gordon P. Hemsley wrote:
>>
>> Perhaps. But maybe I'm not clear on what exactly the alternate
>> proposal is. Are you suggesting not supporting the @download
>> attribute? Or just ignoring it when Content-Disposition specifies a
>> filename? (I would suggest that neither is the appropriate response.)
>
>
> What Gecko implements right now is:
>
> 1)  @download is ignored for non-same-origin links.
> 2)  If Content-Disposition specifies a filename, that filename is used
>     no matter what @download says.

I understand now the motivation for this, but I would think that it
would remove a lot of the usefulness of the @download attribute: If
you have the same origin, you probably already have access to (a) name
the file appropriately in the first place, or (b) set the
Content-Disposition header to send the appropriate filename. No?

>>> This is not trivial, since sniffing can easily fail on files that are
>>> both
>>> HTML and png or both HTML and exe at the same time.  There's a good bit
>>> of
>>> research on things like this.
>>
>>
>> Yes, and that research has already gone into creating the mimesniff
>> standard, has it not? I'm suggesting use the existing algoirthm(s) in
>> an additional arena, not creating a new, separate algorithm.
>
>
> The mimesniff standard doesn't try to sniff for types UAs don't render
> natively, which is what would be needed here.

I'm not so sure about that, but I'll leave it to someone else to
argue. (If you determine a file to be a PNG, then you suggest a .png
extension, regardless of whether there might be an embedded
executable; if you don't support the file format, then how do you know
that it isn't supposed to be an executable in the first place? —and
what is it doing on the Web?)

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