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

[Jonas Sicking]

On Fri, Aug 9, 2013 at 3:53 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Sat, 16 Mar 2013, Jonas Sicking wrote:
>>
>> It's currently unclear what to do if a page contains markup like <a
>> href="page.txt" download="A.txt"> if the resource at audio.wav responds
>> with either
>
> (I'm assuming this is all on the same origin, that there is no script
> changing the various attributes, etc, just the user clicking, that we're
> on a platform with meaningful filename extensions, and that the file is
> returned with an audio/wave type.)

I don't know what "a platform with meaningful filename extensions"
mean. But other than that, "yes".

>> 1) Content-Disposition: inline
[snip]
> This seems unambiguous. Where's the problem?
>
>> 2) Content-Disposition: inline; filename="B.txt"
[snip]
> Again, this seems unambiguous.
>
>> 3) Content-Disposition: attachment; filename="B.txt"
[snip]
> Again, seems clear.

I assume that you realize that there is a problem if you think the
spec is clear, yet people don't understand what the spec intends to
say, or that implementations do different things, that there still is
a problem, right?

>> People generally seem to have a harder time with getting header data
>> right, than getting markup right, and so I think that in all cases we
>> should display the "save as" dialog (or display equivalent download UI)
>> and suggest the filename "A.txt".
>
> I agree that people fail to set headers. But do we have reason to believe
> that people are setting their content-attachment headers with a filename
> incorrectly in the wild?

Yes. Generally speaking people get headers wrong all the time. Even
when they send the headers.

> The problem with ignoring the server in the cross-origin case is that it's
> a security risk (imagine a page trying to cause someone to download a
> sensitive file, but claiming it's a local file with some filename specific
> to the site, and then later asking for it to be uploaded again).
>
> Given that, it seems sane to try to be consistent between cross-origin and
> same-origin cases where possible, which means trusting the server over the
> markup if there's a filename. It seems to me that if a filename is given
> by the server, it's more likely to be right than wrong. (I agree that it's
> more likely that there won't be a filename at all.)

I agree that having cross-origin and same-origin behave differently is
a problem. It's unclear to me if it's a bigger problem than that
people can't override the headers that a same-origin server is
sending.

Note that in this case the problem wasn't with the filename, but
rather with "inline" vs. "attachment". At least if I recall correctly.
It's been a while.

> On Mon, 18 Mar 2013, Jonas Sicking wrote:
>>
>> Over in [1] we immediately ran into people wanting to override an
>> explicitly set header.
>>
>> So no, I don't think that is accurate.
>>
>> I think it is just as common to want to control a situation from markup
>> when you are dealing with a server that is sending a header, as when
>> dealing with a server that is not sending a header. At least if you
>> account for the number of servers setting headers.
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=676619#c117
>
> Well, this is a Mozilla site. Why is a filename set if you don't want it?
> Why would you want that video.ogg file downloaded as "with-target.txt"?

IIRC, the problem here was that the server was always sending
Content-disposition: inline, which made it impossible to use <a
download>.

/ Jonas