I cannot download the Java SDK using FTP from Sun's Java site. Instead of getting a dialog asking me what to do with an "application/octet-stream" thereby giving me the opportunity to save the file to disk, it instead starts loading the file in the browser window. To reproduce: 1) Go to the javasoft URL above. 2) Download the "GNUZIP Tar shell script" version of the SDK. 3) Accept the icky license agreement. 4) Click on the "FTP download" button. 5) The file, all 26MB of it, starts loading in the browser window. 6) Somehow manage to recover from this. I suggest killing Mozilla. 7) Repeat starting at step 1, but this time click on "HTTP download". 8) You are now presented with the dialog asking you what to do with "application/octet-stream". This works ok with NN4. Tested with Mozilla trunk build 2001062212 on Linux.

confirming on win2k using 20010705, built from cvs not sure if the ftp behaviour is incorrect however... will leave that to others to decide

I believe that this is a dup. *** This bug has been marked as a duplicate of 52282 ***

Doug, were not dealing with a .gz file here, this is a .bin file which starts with normal text (it's first lines are part of a shell script). The behaviour mozilla displays doesn't seem incorrect given these facts, but were dealing with a binary file hidden inside a shell script here. The file were dealing with is ftp://ftp.java.sun.com/pub/j2sdk/1.3.1/f198267/j2sdk-1_3_1-linux-i386.bin . It starts with: #!/bin/sh PATH=/usr/bin:/bin libthread_path= more <<"EOF" Sun Microsystems, Inc. Binary Code License Agreement followed by the license, some script and the binary data which is the compressed jdk. Reopening, this is not a dup of 52282 (which is also linux only).

did you read the comments from gagan in that bug?

I don't see how that applies here, .bin is not a defined or obvious extension. In this case it's a script which happens to contain a gzipped file, so in itself it's an example of ambiguity. But i may be wrong, i may not fully understand 52282 and as i do see this bug and not 52282 (which focuses around .gz) they seem different to me as well. If you're sure that a fix for 52282 will be a fix for this bug too, then i'm sorry; i'll shut up and humbly crawl back into my cave. or something

I am a loser - sorry for insisting it was a dup. the problem is the unknown content type hander: http://lxr.mozilla.org/seamonkey/source/netwerk/streamconv/converters/nsUnknownDecoder.cpp#250 It forces the content type to text/html, even though it is not. Cc'in rpotts. Any sage advice?

jud, thoughts?

The unknown decoder was not meant to deal with situations like this :-( I think that the only way to deal with this correctly is to be able to map the '.bin' extension to application/octec-stream. This would prevent the unknown decoder from being invoked in the first place... There is *no* way that the unknown decode can correctly deal with mixed text & binary files and determine the correct mime-type. -- rick

mime problem. Law, do you know who would own this?

Sending over to mscott. This is deeper inside the uriloader and netwerk code than I dare to go.

*** Bug 102433 has been marked as a duplicate of this bug. ***

bill: If I could clarify what you are saying... The problem is that a .bin file does not match anything by the .bin extension, and is going to "unknown decoder", which sends the content to the window as text/html. Since you did not propose it, I assume the solution is more complicated than adding a ".bin" extension entry to the MIME database...

What do you think about this idea: If the browser found a "unknown decoder" you can give the user the control (with a pop up) to save the file to disk or open in the window?

I think there is an RFE for that somewhere.

*** Bug 108133 has been marked as a duplicate of this bug. ***

I believe that this isn't really a bug, and is as designed. To copy my comment from the dupe: "ftp doesn't use mimetypes, so we sniff, and its a plain text file, so its treated as text/plain. Note that if you have a mimetypes file set up to recognise .bin, then we'll use that instead. I have: application/octet-stream bin dms lha lzh exe class in mine, and so the saveas dialog appears" YMMV on other platforms. bz - how do we do extention matching there? Or we could just recognise .bin as application/octet-stream, I guess. Why can't we just do this? That would only solve this issue, but we really can't solve the general case.

I think if there is no mimetype, the next step shouldnt be jumping to sniff it. We should try the extension. Things like .bin should definitely be save to disk. Modifying mime mapping to extensions is a very esoteric activity even on windows - daunting on linux.So we should take care of this for common extensions.

On Windows we just use the registry for extension-matching. On Mac we use internet config, iirc. Something is broken, though. See http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#111 We use that array, but only to do mapping from type to mime info! See http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#266 Right after that we should add a call to GetMIMEInfoForExtensionFromExtras(), which needs to be written.

Err, sorry. I meant to say that we do sniffing only if extention mapping doesn't turn anything up - thats why it works for me, with my mime.type. Note that until recently, we didn't try /etc/mime.types, IIRC, so this won't work on a build older than 3-4 weeks. The fact that we have two mime services with the same contract id (bug 101017) doesn't help trying to work out whats actually going on...

That just adds GetMIMEInfoForExtensionFromExtras() and uses it in both GetTypeFromExtension() (so FTP & co. work) and in DoContent(). Also adds a missing addref in GetMIMEInfoForMimeTypeFromExtras(); I'm surprised this never bit us before. Reviews?

Is this file actually used? Didn't we decide that it was never being called? That would explain why noone actually cared about the missing addref. Or was it the other version which isn't used?

Oh, this file is being used. I tested the patch on the url given (after commenting out the appropriate lines in mime.types). It fixes the problem. It's the _other_ mime service that should not be used. The patch does sort of fix the problem -- it makes us bring up a filepicker instead of opening the file in the browser. Should we do filepicker, or should we pop up the "What do I do with this file" dialog? Oh, and my changes to DoContent() don't seem so great now that I think of them... We should not extension-sniff unconditionally there, since we have a mime type. Attaching new patch.

Taking this to shepherd it through review....

Comment on attachment 56256 [details] [diff] [review] Patch v.2 r=law

*** Bug 54393 has been marked as a duplicate of this bug. ***

Comment on attachment 56256 [details] [diff] [review] Patch v.2 sr=rpotts@netscape.com

Checked in

as I understand it, -> file handling.

clicking on ftp://ftp.java.sun.com/pub/j2sdk/1.3.1/f198267/j2sdk-1_3_1-linux-i386.bin as well as the original test case (clicking on http://www.javasoft.com/j2se/1.3/download-linux.html and so forth) both work --the .bin no longer displays itself in the browser window. i get the help dlg instead. vrfy'd fixed using 2002.06.17.07 comm branch bits on linux rh7.2.