[whatwg] Priority between <a download> and content-disposition
Ian Hickson
ian at hixie.ch
Fri Aug 9 19:47:17 PDT 2013
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list