Closed Bug 54393 Opened 20 years ago Closed 18 years ago

Clicking ftp urls from webpage don't download, instead load binary in content area

Categories

(Core Graveyard :: File Handling, defect, P3, major)

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 87403

People

(Reporter: mikepinkerton, Assigned: mscott)

References

()

Details

- go to http://developer.apple.com/macosx/
- click the "System Disk 3.3" button

expected:
- ftp download window

actual:
- binhex bits in content area

there is a workaround ("save link as" in context menu) but a lot of the time
when you go back, it locks up the machine.
*** Bug 54394 has been marked as a duplicate of this bug. ***
might be a dup of bug 44176
I this still being seen? (bug 44176 was fixed 10/4/00)
OS: All
This is still a problem.
ftp://ftp.cs.umd.edu/pub/skipLists/skiplists.pdf
Clicking that link displays the pdf file as text in the browser window rather
than saving to disk or bringing up your pdf viewer. (Linux build 2000110621)

Since ftp doesn't have a mime type associated with it, I believe this all needs
to be handled by file extension.
Since this shows up on Linux, changing to platform ALL.
Hardware: Macintosh → All
Be careful here. If you use a ftp proxy, like squid, you will get a synthesized
MIME type. You may not want to muck that up.
ftp bugs to component:ftp
Assignee: gagan → dougt
Component: Networking → Networking: FTP
Target Milestone: --- → M19
Blocks: 61688
Blocks: 62354
Scott, per email, I am assigning you my MIME related bugs.  
Assignee: dougt → mscott
*** Bug 55580 has been marked as a duplicate of this bug. ***
The problem here is that ftp just has an extention to use to find a mime type.
If we can't find one then we falls back to the unknown content type handler.
Since a pdf file is mainly text, it decides that its text/plain, and we display
the file.

What you have to do is make sure that mozilla knows how to do this mapping. For
various reasons (including the fact that we somehow have two objects registering
with the same contractid) we don't look at the helper app prefs. On unix, we use
mime.types if you set the prefs correctly. bz checked in a couple of patches
this evening - one to make extention matching not case-sensitive, and another to
change the defaults on unix for mime.types to be sensible (/etc/ rather than
/usr/lib/netscape/). This should appear in tomorrows builds, and with just the
pref change pdf files load correctly via ftp on 0.9.4 on linux.

I have no idea how other platforms do this matching..
Call me crazy, but this seems fixed on the Linux nightly builds for 9/24
(2001092408).  PDFs open in my registered Helper App, not in the browser window.
 Are other platforms working too?
Linux builds will now read /etc/mime.types, and pdf is almost certainly
mentioned in there.
This is probably still a bug on Linux -- the system-defined MIME types override
Mozilla's helper app selections.  Since the helper app is defined by the user,
shouldn't that be given priority, and the system MIME type used as a fallback? 
I'm not sure about this, and my brain hurts anyway.
> the system-defined MIME types override Mozilla's helper app selections

Actually, the problem there is that Mozilla's helper app selections don't seem
to do extension -> helper mapping!  Yes, it's in the UI, but the back end is
doing something weird.  I'm planning to look into this in detail one of these
days...  Since FTP does not serve a content-type, we use extensions and then we
can't use the helper app selections, as far as I can tell.
QA Contact: tever → benc
for the record:
RFC 1630 and RFC 1738 are consistent in this area, looking at extensions is the 
only way of determining the file type.

Is this bug the "FTP on allplats should use file extensions -> MIME", or is it 
only about Linux now? (it's marked "ALL/ALL")
benc: See bz's comment. this is more about: "I need once place I can call to
give me the result"
Looks like the /etc/mime.types fix for Linux is broke again or checked out.  It
sounds like the solution was moving in the direction of a cross-platform
extension-to-mimetype matching function, so the Linux-only fix may have just
been checked out.  Either way, it's not working on Linux anymore, FYI.
Thanks, Boris.  Yes, I've recently switched from RedHat to Mandrake, and lo and
behold, Mandrake doesn't use an /etc/mime.types file.  A lot of trouble to go
through for CUPS, sheesh.  Sorry for the spam.
I read over this bug, and I am confused.  The original bug was specifically about 
BinHex (".bin") on MacOS.  This should be handled by internet config.  I don't 
believe the internet config stuff was completely hooked up when Mike filed this 
bug....  Mike, could you possibly retest the _original_ problem?

When not on MacOS, we should map .bin to application/octet-stream.  The bug for 
getting that hooked up is bug 87403 (has a patch)

> system-defined MIME types override Mozilla's helper app selections

Bug 109236 (has a patch)

So is this bug about having the unknown content decoder be smarter?  In that case 
we need a particular file on which it fails when it should not.

I'm very tempted to mark this worksforme (if it works for Mike) and tell all the 
linux users to install the mailcap package like they should.
just tried with 6.2 and it seems to be working now. should we keep this open for
any other issues?
resolving duplicate of bug 87403 since this works on Mac now and on non-mac
platforms we will do the right thing once that bug is fixed.

*** This bug has been marked as a duplicate of 87403 ***
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
-> file handling, as I understand it.
Component: Networking: FTP → File Handling
QA Contact: benc → sairuh
marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.