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

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

> 1) Content-Disposition: inline

You go down the "as a download" algorithm, as follows:

 1. filname = void
 2. doesn't apply
 3. interface origin = origin A
 4. resource origin = origin A
 5. trusted operation = true, since they're the same
 6. doesn't apply
 7. doesn't apply
 8. proposed filename = "A.txt"
 9. filename = proposed filename, "A.txt"; jump to 13
13. allow user to influence filename; let's assume user does not
14. filename looks ok, so nothing changes
15. doesn't apply
16. claimed type = {audio/wave -> wav}; named type = {text/plain -> txt}
17. doesn't apply given assumption in step 13
18. doesn't apply
19. filename becomes "A.txt.wav"
20. return "A.txt.wav"

This seems unambiguous. Where's the problem?


> 2) Content-Disposition: inline; filename="B.txt"

You go down the "as a download" algorithm, as follows:

 1. filename = void
 2. doesn't apply
 3. interface origin = origin A
 4. resource origin = origin A
 5. trusted operation = true, since they're the same
 6. filename = "B.txt", jump to 13
13. allow user to influence filename; let's assume user does not
14. filename looks ok, so nothing changes
15. doesn't apply
16. claimed type = {audio/wave -> wav}; named type = {text/plain -> txt}
17. doesn't apply given assumption in step 13
18. doesn't apply
19. filename becomes "B.txt.wav"
20. return "B.txt.wav"

Again, this seems unambiguous.


> 3) Content-Disposition: attachment; filename="B.txt"

You go down the "as a download" algorithm, as follows:

 1. filename = void
 2. filename = "B.txt", jump to 13
13. allow user to influence filename; let's assume user does not
14. filename looks ok, so nothing changes
15. doesn't apply
16. claimed type = {audio/wave -> wav}; named type = {text/plain -> txt}
17. doesn't apply given assumption in step 13
18. doesn't apply
19. filename becomes "B.txt.wav"
20. return "B.txt.wav"

Again, seems clear.


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

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


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

The only way you can end up using the download="" attribute's value in the 
cross-origin case is if the server says Content-Disposition:attachment but 
doesn't include a filename.


> Nor do I think that simply using a different filename is going to 
> meaningfully protect downloaded content.

I think it's a heck of a lot more likely that you can trick someone into 
uploading "highscores.dat" or "cartoon-profile.jpeg" than it is that you 
can trick them into uploading "John-Doe-bank-account-8172002.csv".


> So I think a stronger UI warning is needed in this scenario.

Steps 12 and 13 of the "as a download" algorithm, 12 in particular, are 
all about this. That's what all the warning text in step 12 says, 
including: "it is in the user's interests that the user be somehow 
notified that the resource in question comes from quite a different 
source, and to prevent confusion, any suggested file name from the 
potentially hostile interface origin should be ignored".


On Sun, 17 Mar 2013, Glenn Maynard wrote:
> 
> "inline" is only there because it has to be; there's no way of saying 
> "Content-Disposition: don't care; filename=foo".  "inline" is the 
> default.
> 
> I think @download should be able to force a download regardless of 
> whether a C-D header exists: treat the default C-D as "inline", and 
> don't change behavior just because a header states the default.

I believe this is consistent with the spec, modulo the cross-origin issues 
discussed above.


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

It seems to me that this is working as intended. The page is setting bogus 
filenames, the server is setting a good one, the good one is winning.


On Wed, 8 May 2013, Gordon P. Hemsley wrote:
> 
> Here's what the spec says:
> 
> "The download attribute, if present, indicates that the author intends 
> the hyperlink to be used for downloading a resource. The attribute may 
> have a value; the value, if any, specifies the default file name that 
> the author recommends for use in labeling the resource in a local file 
> system."
> 
> I interpret that first sentence to mean that the file should be 
> downloaded (disposition type = attachment) rather than displayed 
> (disposition type = inline). The second sentence very clearly suggests 
> that "A.txt" would be the filename presented to the user by default in 
> the save dialog.

There's much more specific text later in the spec that answers this in 
much more detail.

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

Received on Friday, 9 August 2013 22:53:42 UTC