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

I realize this is an old thread, so apologies if this has already been
resolved. The discussion that originally followed seemed to have
gotten off track, so I wanted to try to clarify things.

First off, there are two factors to consider:
(1) Whether to download the file or display it.
(2) What filename to suggest for the file when it is downloaded.

In the general case, with a normal <a href> and no Content-Disposition
header (or the plain 'Content-Disposition: inline' header, listed as
(1) originally), the answers are:
(1) Display it.
(2) Whatever the filename on the server is (e.g. "page.txt" or
"example.php"), modulo OS restrictions.

In the case of a normal <a href> and a 'Content-Disposition: inline;
filename="B.txt"' header (listed as (2) originally), the answers are:
(1) Display it.
(2) "B.txt"

Changing the disposition type doesn't change much, with a normal <a
href> and a 'Content-Disposition: attachment; filename="B.txt"' header
(listed as (3) originally):
(1) Download it.
(2) "B.txt"

So now, the question is, what effect does a @download attribute have?
Nothing too surprising.

An empty @download attribute would override the 1st factors above so
that they are always "Download it."

A @download attribute with a value would override both factors, like so:
(1) Download it.
(2) "A.txt"

Thus, the @download attribute acts to override the Content-Disposition
header, giving the following hierarchy:


@download > Content-Disposition > URL


Or, in pseudocode (with the assumption that if X has Y, then X is also present):


disposition_type = ( @download is present ) ? "attachment" : ( (
Content-Disposition header is present ) ? Content-Disposition
disposition type : "inline" );
suggested_filename = ( @download has a value ) ? value of @download :
( ( Content-Disposition has filename parameter ) ? Content-Disposition
filename value : filename from URL );


I don't see what the security concerns might be: There is no
difference here than what is already available, except that there's
now an additional way to specify it. AFAICT, there are no content
sniffing or cross-domain issues at play. Browsers already give strange
results when saving a file; they don't do any file extension vs. file
format checking. (For example, the output of a .php or .cgi or .py
file on a server is usually HTML, yet browsers don't generally make
any attempt to change the file extension to .html when saving the
file, IME.)

Does this make sense? Am I missing anything?

Regards,
Gordon


On Sat, Mar 16, 2013 at 9:49 PM, Jonas Sicking <jonas@sicking.cc> 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
>
> 1) Content-Disposition: inline
> 2) Content-Disposition: inline; filename="B.txt"
> 3) Content-Disposition: attachment; filename="B.txt"
>
> 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".
>
> The spec is currently defining something else at least for 3.
>
> Potentially there are reasons to do something different in the case
> when the linked resource lives off of a different origin since in that
> case there might be security reasons to use the filename or
> disposition of the server that is actually serving up the content.
> However I don't think we can expect people to indicate
> "Content-Disposition: inline" in order to protect resources. Nor do I
> think that simply using a different filename is going to meaningfully
> protect downloaded content. So I think a stronger UI warning is needed
> in this scenario.
>
> Firefox currently doesn't support cross-origin @download references,
> so I don't have any meaningful implementation experience to share
> regarding that scenario.
>
> / Jonas



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

Received on Tuesday, 7 May 2013 21:55:42 UTC