If Mozilla (the Carbon version, build 2002061014) attempts to, using the http protocol, open foo.dmg.gz, it begins to open in the browser (lots of gibberish everywhere). The correct behaviour would be to recognise it as a .gz file and download it, as it does with bar.gz. This behaviour, and why it is a problem, can be seen at http://www.versiontracker.com/php/dlpage.php?id=15356&kind=1&db=macosx - at this site, a .dmg.gz download attempts to start automatically. Unfortunately, it succeeds - but isn't a download after all.

F:\build\mozilla\nsprpub\lib\ds>wget http://s.sudre.free.fr/Software/files/Euphoria.dmg.gz --11:42:29-- http://s.sudre.free.fr:80/Software/files/Euphoria.dmg.gz => `Euphoria.dmg.gz' Connecting to s.sudre.free.fr:80... connected! HTTP request sent, awaiting response... 200 OK Length: 208,745 [text/plain] The server needs to server .dmg as a binary type, nc4 tries to render the file, and I don't blame it. Note: in http, a URI has a content type, it doesn't have one extension or two extensions or three extensions. The server is responsible for providing the content type, and the browser is responsible for honoring it.

Well, I just ran a couple of tests, and the problem occurs when a .dmg.gz is served from default installations of either Apache or IIS. Between the two, that's a heck of a lot of .dmg.gzs that aren't going to download, so maybe a workaround would be advisable.

Confirmed using FizzillaCFM/2002062203. The server sends the .gz file as "text/plain" when it should be using "application/x-gzip". FWIW, ftp.mozilla.org isn't configured right, either. See bug 153387.

I am having the same problem with versiontracker .gz files Mozilla would be more user-friendly if it assumed the suffix took precedence over the MIME type, since webmasters are more likely to add the .gz suffix properly than to encode the MIME type properly.

The (to me) silly thing about the MIME spec is that it doesn't specifically say what to do when the server of the content doesn't know what it is. Apache ships by default configured to say "text/plain" and recommends also "application/octet-stream" or whatever. Is there a MIME type of "none" or "unknown/unknown"? I can't find it. If most servers are saying, "if I don't know the mime type, i'll send text/plain" (which is certainly the case for Apache) then I think we need to consider that the servers are working around the MIME spec's lack of an "unknown" type. Given that most servers (including IIS AFAIK) implement this workaround, chimera should perhaps consider following the server workaround with an equivalent client workaround. Which means trying to guess, IMHO. From the other side, how often do text/plain files have an extension that is wrong. In other words, I think it's rare to find a file that's declared text/plain and really is a plain text file, but has an extension that contradicts that. I vote to implement a workaround when Chimera receives a text/plain or application/octet-stream file with an extension; and to follow up with the MIME folks and the server folks with a request to please fix the server-side problem.

application/octet-stream is the type to use for unknown formats readme.1st would be a common text file with a non-text extension

Should each instance of server misconfiguration be a separate bug, or is this one a dupe of bug 137532?

since this is tech evang, each site should be a different bug since we need to contact them both. fix is : well, dont use text/plain :) contact is : webmaster@free.fr (anyone got a better one ?) updading summary as it happens on every site hosted by free.fr .

I can confirm that this bug is still present in Mozilla 1.3. http://www.versiontracker.com/redir.fcgi/kind=1&db=macosx&id=17101/whatroute-1.8.14.dmg.gz MacOS X 10.2.5.

*** This bug has been marked as a duplicate of 135411 ***

tech evang june 2003 reorg

VERIFIED