Closed Bug 210229 Opened 17 years ago Closed 16 years ago

Helper app Window for text/html document (two comma-delimited charsets in http content-type header)

Categories

(Core :: Networking: HTTP, defect, P2, major)

defect

Tracking

()

VERIFIED FIXED
mozilla1.5beta

People

(Reporter: Matti, Assigned: darin.moz)

References

()

Details

(Keywords: regression)

Attachments

(2 files)

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[205.188.226.216]: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 )
Attached image screenshot
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....
Blocks: 210513
*** Bug 210921 has been marked as a duplicate of this bug. ***
Blocks: 212714
No longer blocks: 212714
*** 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. ***
Attached patch v1 patchSplinter Review
Attachment #128903 - Flags: superreview?(bz-vacation)
Attachment #128903 - Flags: review?(cbiesinger)
Attachment #128903 - Flags: superreview?(bz-vacation) → superreview+
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
Closed: 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. ***
v.
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.