MozillaZine

Branch Cut for Mozilla Firebird 0.8

Wednesday December 17th, 2003

A branch has been created for the forthcoming release of Mozilla Firebird 0.8. The branch will allow Firebird 0.8 work to continue without the uncertainty caused by the daily changes made to the main Mozilla development trunk (currently frozen for Mozilla 1.6). However, critical trunk fixes will be merged into the new Firebird 0.8 branch.

Nightly builds from the branch will be available soon. They will feature a new mechanism for handling files served with a text/plain MIME type and new front end for XPInstall (the code used for installing things like extensions). Read Ben Goodger's post to the Firebird General forum for more information about the 0.8 branch.


#15 Re: Re: re: MIME fix

by jgraham

Thursday December 18th, 2003 10:07 AM

You are replying to this message

If you read the bug report, it's not nearly so bad as it sounds. In 99% of cases the mime type is used as it should be. In the specific case that the connection is HTTP (i.e. the patch doen't affect ftp or anything else), the content type is text/plain, and there is no character encoding set (or there is the Apache 2 default chracter encoding set) then Mozilla will attempt to determine the content type - initially by looking for the presence of particular features such as ascii control codes then (Windows only) looking at the file name extension. This situation is not substantially worse than before, since content without a proper character set header has always been run though a sniffer to try and determine the encoding being used - the standards dictate in this case that it should be displayed as US-ACSII instead.

This differs substanitially from the current behavior of IE in that there are very few situations in which content served from a correctly set up server will be handled incorrectly. As far as I can tell, in order to trigger the misintepretation of a legitamate text/plain document, you'd need to meet the follwoing criterion: No specified encoding (i.e. rely on the US-ASCII default) or ISO-8859-1 encoding, no leading byte order mark (I guess a legitimate ASCII document won't have a BOM since they're 1 byte/character - this check prevents UTF-16 from being detected as binary), includes ASCII control characters in the range 0-8, 13-26 or 28-31.