Closed Bug 87403 Opened 23 years ago Closed 23 years ago

ftp: .bin file displays in window

Categories

(Core Graveyard :: File Handling, defect, P1)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.7

People

(Reporter: smoehle, Assigned: bzbarsky)

References

()

Details

Attachments

(1 file, 1 obsolete file)

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
I believe that this is a dup.

*** This bug has been marked as a duplicate of 52282 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
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).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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?
Summary: Cannot download Java SDK using FTP → unknown decoder assumes scripts with embedded binaries are plain text.
Target Milestone: --- → mozilla1.0
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?
Assignee: dougt → law
Status: REOPENED → NEW
Sending over to mscott.  This is deeper inside the uriloader and netwerk code
than I dare to go.
Assignee: law → mscott
QA Contact: tever → benc
*** 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...
Summary: unknown decoder assumes scripts with embedded binaries are plain text. → ftp: .bin file displays in window
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...
Attached patch proposed patch (obsolete) — Splinter Review
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.
Attachment #56251 - Attachment is obsolete: true
Attached patch Patch v.2Splinter Review
Keywords: patch, review
Taking this to shepherd it through review....
Assignee: mscott → bzbarsky
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: mozilla1.0 → mozilla0.9.7
Comment on attachment 56256 [details] [diff] [review]
Patch v.2

r=law
Attachment #56256 - Flags: review+
*** Bug 54393 has been marked as a duplicate of this bug. ***
Checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago23 years ago
Resolution: --- → FIXED
as I understand it, -> file handling.
Component: Networking: FTP → File Handling
QA Contact: benc → sairuh
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.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: