- 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)

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.

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

Scott, per email, I am assigning you my MIME related bugs.

*** 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.

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 ***

-> file handling, as I understand it.

marking verified as a duplicate. if you decide to reopen this bug, please clarify why. search string for bugspam removal: SalviaGuaranitica