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

On 2013-03-19 15:31, Nils Dagsson Moskopp wrote:
> Roger Hågensen <rescator@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/

Received on Tuesday, 19 March 2013 20:35:55 UTC