- From: Glenn Maynard <glenn@zewt.org>
- Date: Sun, 17 Mar 2013 09:57:33 -0500
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Jonas Sicking <jonas@sicking.cc>
On Sun, Mar 17, 2013 at 6:46 AM, Julian Reschke <julian.reschke@gmx.de>wrote: > 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". >> > > I agree that people have problems getting headers right, but in all the > cases above, it seems they have set the header on purpose, no? > > My recollection was that a/@download was mainly added for cases where the > header field couldn't be set at all... > When I use #2, I'm just setting the filename. "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 don't know if it should be able to override a C-D filename parameter. I can't think of any case where this is useful, so if it helps get this feature available cross-origin then that's fine. (Half of the point of this feature is to allow adjusting filenames on external content servers which you don't have much control over.) -- Glenn Maynard
Received on Sunday, 17 March 2013 14:57:58 UTC