[whatwg] Priority between <a download> and content-disposition
Roger Hågensen
rescator at emsai.net
Tue Mar 19 13:35:28 PDT 2013
On 2013-03-19 15:31, Nils Dagsson Moskopp wrote:
> Roger Hågensen <rescator at emsai.net> schrieb am Tue, 19 Mar 2013
> 14:31:15 +0100:
>
>> […]
>> What should be shown if there is an issue/conflict?
>>
>> Maybe:
>> Download "https://example.com/reports/1/xml/" as "report1.xml" ?
>> WARNING! File identified as actually being an executable! (*.exe)
> At least here on Debian GNU/Linux, executables have no file extension.
> Besides that, what would be the MIME type of windows executables?
application/octet-stream as far as I know for most exes and misc
binaries on most platforms, and windows exe's start with "MZ" as the
very first two bytes.
>
>> Or:
>> Download "https://example.com/reports/1/xml/" as "report1.xml" ?
>> NOTE! File identified as not being a xml, appears to be text. (*.txt)
> So, what about polyglots?
> <http://linux-hacks.blogspot.de/2009/02/theory-behind-hiding-zipped-file-under.html>
Data hiding? (well close to it anyway) That is way beyond the scope of
this, also I doubt you could do that with a executable on most platforms.
And if a .jpg turns out to have a zip attached then it just a .jpg with
a zip attached, it's as simple as that.
>> The key though is showing: Download "url" as "file.ext" ?
>> And in cases where a quick file header scan reveals a possible issue
>> (or simply wrong fileformat extension) either a notice or warning
>> text in addition.
>> But this is only if the user actually hose "Save As" in the download
>> dialog, they might have chosen "Share on facebook" or "Print" or
>> "Email to..." or even "Open"
>> a similar but different dialog would obviously be needed in that case.
> I find all of this approach insanely complex for a negligible benefit.
>
How so? All the information is mostly there. (HTTP header from server is
always fetched be it HEAD, GET, POST calls, and a browser usually
fetches the beginning of a file to sniff anyway).
The suggested name and extension would be in the download attr, and href
is as it's always been.
Today if you download/run a link to a exe you do get asked if you really
want to run this. (and this is a browser UI not a OS UI).
What is so complex about simply adding : as "file.ext ?
to that UI which is already there?
In cases where the download attr and href and the server header and
browser sniffing all agree it looks no different (nor behaves any
different) than it does today when you right click and choose "Save As...".
What is so complex about just suggesting some consistency in behavior
with a improvement to boot?
And if you refer to the "Share on/at..." or "Email to..." or Print or
Open then those are dialog options that do exist today or will, and was
just used as examples and is not otherwise part of this in any other way.
Maybe there is a language barrier here and I'm not explaining this
correctly, in which case I apologize for that. Let me know if anything
in particular needs clarification.
--
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/
More information about the whatwg
mailing list