User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021128 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3a) Gecko/20021128 the page is not the usual displayed html source caused by wrong mime type there is also an encoding issue. Page works with IE If is an evangelize matter http://www.sony-europe.com/ is worth some effort Reproducible: Always Steps to Reproduce: 1.open http://www.sony-europe.com/cds/showpage.asp?nodeid=90734 Actual Results: strange stuff is displayed Expected Results: page displayed
The page starts with hex chars "FF FE", which indicates little-endian byte order UTF-16. However, the page is sent as UTF-8. Although this is technically Sony's fault, I believe that Mozilla should handle this situation more gracefully by allowing BOM Quirks Mode. Two mistaken bytes should not prevent the entire page from displaying. % curl -I http://www.sony-europe.com/cds/showpage.asp\?nodeid=90734 HTTP/1.1 200 OK Server: Microsoft-IIS/4.0 Date: Sun, 23 Feb 2003 02:09:29 GMT Content-Length: 4592 Content-Type: text/html; Charset=UTF-8 Set-Cookie: ASPSESSIONIDGGQGGQCB=CBHLJHGCENAOLCNHFEBFALIC; path=/ Cache-control: private
Assignee: asa → smontagu
Status: UNCONFIRMED → NEW
Component: Browser-General → Internationalization
Ever confirmed: true
OS: Windows 98 → All
QA Contact: asa → ylong
Hardware: PC → All
Summary: provided url not displayed properly → sony-europe.com - FF FE on UTF-8 page, Mozilla displays code
If bug 183354 gets fixed, the charset detector should be able to handle cases like this.
Depends on: 183354
I don't think bug 183354 will fix this. This is a case of wrong charset being specified in HTTP header. The document is UTF-16LE, but the HTTP header insists it's UTF-8. So to display the page, Mozilla would have to override the charset specified in header, and as far as I know that would be an incorrect behaviour (unless done by user's request). At the moment Mozilla does what's right. bug 183354 fixes the Universal Charset Autodetector. As far as I understand, this code kicks in only when charset is not specified in HTTP header. However bug 68738 might have some effect on this, for it checks the BOM on Parser level. However I'm not sure in what cases that code gets executed. This is an interesting testpage, and it would be interesting to see how Mozilla's behaviour will be affected by these 2 patches. But this belongs to Evangelism.
Depends on: 68738
I agree with Alexey. This is an edge(and evngelism) case and Sony should fix this non-sense right away. I'm not sure how Mozilla should handle this case without violating the standard. Adding a user-preference (not available in UI) to give a higher precedence to autodetectors(including BOM detection) than to http header??
Another problem is that right now the UTF-16 encodings are not readily available from any menu, so a user will have a problem overriding manually.
To evangelism anyway.
Component: Internationalization → Europe: West
Product: Browser → Tech Evangelism
Version: Trunk → unspecified
Assignee: smontagu → nitot
QA Contact: ylong → brantgurganus2001
move tristans bugs to other
Assignee: nitot → other
Component: Europe: West → Other
QA Contact: brantgurganus2001 → other
page no longer exists. dependencies been fixed.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.