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

[Ian Hickson]

On Fri, 9 Aug 2013, Jonas Sicking wrote:
> 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. 

One in which a file's name decides its processing.

So for example, Windows is such a platform. When you tell Windows to 
invoke a file, it examines the part of the name after the final dot, looks 
that string up in a registry, and uses the information there to decide how 
to invoke the file.

Most Unix shells are examples of platforms that are not extension-based. 
If you tell Bash to execute a file, it examines the file's contents to 
determine how to invoke it (e.g. looking for hash-bangs).


> 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?

Yes, that's why I asked "where's the problem". :-)

I don't understand why the spec is ambiguous. Can you elaborate?


> >> 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.

Fair enough. (I would feel more comfortable with this if we had data 
specifically for this header, but let's move on.)


> 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.

I don't know.


> 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.

I'm not sure I know what problem you're referring to here.


> > 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>.

Content-disposition: inline doesn't make it impossible to use download="" 
according to the spec as far as I can see.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'