Closed
Bug 87403
Opened 23 years ago
Closed 23 years ago
ftp: .bin file displays in window
Categories
(Core Graveyard :: File Handling, defect, P1)
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: smoehle, Assigned: bzbarsky)
References
()
Details
Attachments
(1 file, 1 obsolete file)
3.47 KB,
patch
|
law
:
review+
rpotts
:
superreview+
|
Details | Diff | Splinter Review |
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
Comment 2•23 years ago
|
||
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 → ---
Comment 4•23 years ago
|
||
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
Comment 6•23 years ago
|
||
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
Comment 7•23 years ago
|
||
jud, thoughts?
Comment 8•23 years ago
|
||
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
Comment 9•23 years ago
|
||
mime problem. Law, do you know who would own this?
Assignee: dougt → law
Status: REOPENED → NEW
Comment 10•23 years ago
|
||
Sending over to mscott. This is deeper inside the uriloader and netwerk code than I dare to go.
Assignee: law → mscott
Comment 11•23 years ago
|
||
*** Bug 102433 has been marked as a duplicate of this bug. ***
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
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?
Comment 14•23 years ago
|
||
I think there is an RFE for that somewhere.
Comment 15•23 years ago
|
||
*** Bug 108133 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
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.
Assignee | ||
Comment 18•23 years ago
|
||
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.
Comment 19•23 years ago
|
||
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...
Assignee | ||
Comment 20•23 years ago
|
||
Assignee | ||
Comment 21•23 years ago
|
||
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?
Comment 22•23 years ago
|
||
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?
Assignee | ||
Comment 23•23 years ago
|
||
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.
Assignee | ||
Updated•23 years ago
|
Attachment #56251 -
Attachment is obsolete: true
Assignee | ||
Comment 24•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Assignee | ||
Comment 25•23 years ago
|
||
Taking this to shepherd it through review....
Assignee: mscott → bzbarsky
Assignee | ||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: mozilla1.0 → mozilla0.9.7
Comment 26•23 years ago
|
||
Comment on attachment 56256 [details] [diff] [review] Patch v.2 r=law
Attachment #56256 -
Flags: review+
Assignee | ||
Comment 27•23 years ago
|
||
*** Bug 54393 has been marked as a duplicate of this bug. ***
Comment 28•23 years ago
|
||
Comment on attachment 56256 [details] [diff] [review] Patch v.2 sr=rpotts@netscape.com
Attachment #56256 -
Flags: superreview+
Assignee | ||
Comment 29•23 years ago
|
||
Checked in
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 30•22 years ago
|
||
as I understand it, -> file handling.
Component: Networking: FTP → File Handling
QA Contact: benc → sairuh
Comment 31•22 years ago
|
||
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
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•