win2k and todays CVS build and sirLurxalot confirmed it on Linux a) open the URL b) get a helper app window (see the attachment) wget -S http://members.aol.com/elgrognard/successors/pbem1.htm --02:09:52-- http://members.aol.com/elgrognard/successors/pbem1.htm => `pbem1.htm.2' Resolving members.aol.com... done. Connecting to members.aol.com[184.108.40.206]:80... connected. HTTP request sent, awaiting response... 1 HTTP/1.1 200 OK 2 Date: Sun, 22 Jun 2003 00:09:53 GMT 3 Server: Apache/1.3.26 (Unix) Resin/2.0.5 4 Connection: close 5 Content-Type: text/html; charset=Shift_JIS,ISO-8859-1 This is a regression because 1.3 displays it as HTML (works as well in a 1 week old FB build from sirLurxalot )
Sounds like a regression from those recent content-type parsing changes.... Confirming with a current CVS build on Linux.
Severity: normal → major
OS: Windows 2000 → All
Hardware: PC → All
Oh, the MIME type we come out with for this site is "iso-8859-1", which is indeed what the Content-Type header says.... Depending on how common this particular server bug is we _may_ want to evangelize it....
*** Bug 210921 has been marked as a duplicate of this bug. ***
*** Bug 212714 has been marked as a duplicate of this bug. ***
*** Bug 213900 has been marked as a duplicate of this bug. ***
*** Bug 214022 has been marked as a duplicate of this bug. ***
Tweaking summary to try and help make finding this bug easier, as the dup's keep coming in.
Summary: Helper app Window for text/html document → Helper app Window for text/html document (two comma-delimited charsets in http content-type header)
*** Bug 214277 has been marked as a duplicate of this bug. ***
someone posting in the forums - http://forums.mozillazine.org/viewtopic.php?t=17752 reports a similar issue which I guess is caused by the same change. The example is a Netscape server with an even more screwed up content-type: Server: NetWare-Enterprise-Web-Server/5.1 Date: Wed, 30 Jul 2003 16:07:09 GMT Content-type: text/html;�l]ÕÀuÅÕE,DÕ`0Ñp.•Ò`0Ñô ÑÐ Ñ�l]ÕÀuÅÕ(DÕp.•Ò Connection: close and also results in the download/helper app dialog appearing.
this is probably related to my changes in nsHttpResponseHead::ParseContentType.
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.5beta
perhaps we can reject a "mime-type" if it does not contain a single '/' ??
That seems like a reasonable course of action to me... I can't think of any pages sending correct info that would get broken by that. ;)
*** Bug 214536 has been marked as a duplicate of this bug. ***
Attachment #128903 - Flags: superreview?(bz-vacation) → superreview+
16 years ago
Attachment #128903 - Flags: review?(cbiesinger) → review+
fixed-on-trunk, with this change: strchr(type, '/') instead of strchr(type, "/") which was just a typo ;-)
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
*** Bug 215322 has been marked as a duplicate of this bug. ***
*** Bug 216611 has been marked as a duplicate of this bug. ***
Why was it parsing the "ISO-8859-1" as the content type, anyway? It looks like that is part of the "charset" attribute... a broken value (since there's no logical reason to have two charsets separated by a comma; a document can only be in one character encoding at a time), but not affecting the content type of "text/html". Somebody should evangelize AOL about their members.aol.com server returning a broken header, anyway.
Dan: The HTTP Spec requires parsing that header just like mozilla did parse it. Content-Type: foo,bar is supposed to be treated exactly like: Content-Type: foo Content-Type: bar
*** Bug 218759 has been marked as a duplicate of this bug. ***
Just adding some of the things real people use to search for this bug: Firebird won't open page, keeps wanting to download it Unable to open iso-8859-1? Error about displaying ISO-8859-1 (does not know how to handle filetype "" (Null) won't view the url, instead shows the does not know how to handle this file type dialog A window asking me where to save the page appears instead of rendering the page. Commas in Content-Type headers cause great confusion Messed up Content-Type header leads to problems HTTP Header includes two entries following CHARSET states that index.html is of type iso-8859-1 and that Mozilla Firebird does not know how to open this type of file. (Because I spent over an hour searching through Bugzilla, but still ended up entering a duplicate of this bug.)
*** Bug 219076 has been marked as a duplicate of this bug. ***
*** Bug 219158 has been marked as a duplicate of this bug. ***
*** Bug 219224 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
Somebody should still evangelize AOL about changing their bogus header; even though Mozilla has been "fixed" to do better error-correction on this, it still causes problems. All members.aol.com pages are now regarded by Mozilla as being of charset Shift_JIS, a Japanese character set, which produces odd font choices and misrendering of non-Japanese special characters (any use of iso-8859-1 or windows-1252 characters causes Japanese characters to display instead).
The other problem is that the latest 'milestone' version of Firebird (the one that is recommended for new users who want a more stable version than the nightly releases) still has this bug. Until a newer milestone is released, duplicates of this will likely keep popping up. (I've tried telling AOL about this, but it's almost impossible to find a customer support contact that actually knows what the heck an http header is.)
Feel free to file an evangelism bug on the issue, but this bug was about the technical problem, which is resolved.
The evangelism issue with AOL is the subject of bug 212714 which I just re- opened. (It was previously closed as a dup of this bug.)
You need to log in before you can comment on or make changes to this bug.