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 <jo...@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 m...@gphemsley.org http://gphemsley.org/ • http://gphemsley.org/blog/
