Re: Frequent incorrect guesses by the charset autodetection in IE7

From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Thu Jul 13 2006 - 20:51:50 CDT

  • Next message: James Kass: "Re: Frequent incorrect guesses by the charset autodetection in IE7"

    From: "Paul Nelson (ATC)" <paulnel@winse.microsoft.com>
    > Are you using the IE 7 Beta 3 that was put on the web
    > (http://www.microsoft.com/windows/ie) when you see this behavior?

    Absolutely, yes. And the same bug occurs in IE7 Beta2 (but LESS often).

    Well, I must admit that IE7 is still not available in French localization, so I use the English version (I did not try the German version, but i suppose it only differs by its localized UI, but not in this core feature which should be part of all localized versions).

    Nothing wrong like this occurs in Firefox or IE6 (there are rare occurences where the charset detection is wrong in any browser, but this only affects pages with nearly no text content).

    Note that the bug is reproduced also in Spanish pages of the Red Cross. As the bugs are very visible on these pages, and occurs almost always, the content of this web site can be used as a testcase for the autodetection mechanism. (The Red Cross websites are programmed with ASP, and use all Microsoft technologies, including for the web server itself, and OLEDB interfaces to MS databases).

    If the charset specification is not easy to set for website authors, it can't be blamed too much on them, and Microsoft really needs to assist website designers when they use MS tools to build sites. Many web site designers know how to set easily the charset and set HTTP headers using comptetive products and have many solutions depending on the centext, but in the ASP area, very few do know how to set it consistently, or they are lost in various APIs, or setting an option in the web server for the MIME type is not as easy as on Apache servers.

    This can be seen as a deployment problem, and a place where testing procedures for a designed web site are missing in the MS web design toolkits and frameworks. Note that the bug spoken here involves ONLY Microsoft products supported by Microsoft, either with a contractual supprot for a release, or with a community support for beta versions in pre-release (public) stages.

    Since I use IE7 beta3, I see lots of sites in French now broken. Generally, the largest portals are not affected because they do specify a charset explicitly, but the web is larger than large portals.

    Also the case of large commercial portals is not an issue: users can legitimately expect a correction by the portal itself, which should have a good skilled, and trained development and design team available to make corrections rapidly (this is a daily job for them, as they permanently create new content for the portal, and must create new interfaces to integrate third party contents or ads or to manage online shops, or to manage the customers databases and network infrastructure, so adding a forgotten charset should not be a problem for them).

    --
    Philippe.
    Note: after a non-delivery report, this is reported to the list where I'm still not blocked, as the content of my message is not secret, and as James Kass did not receive it in his AT&T mailbox; i could have delivered it the first time to the list.
    (Out of topic: AT&T currently blocks all emails from Orange, my ISP, even though I use the regular Orange's SMTP server and don't use my own MTA. It's really irritating to see such blocking between large ISPs, because I receive tons of spam from AT&T subscribers too at incredible rate each day, much more than from Orange users... I hope this blocking is temporary, but I thought that there were cooperation agreement between Orange and large ISPs to fight spam in a way different from the blocking of their recommanded and supported SMTP servers... When will ISPs collaborate more efficiently so that only the effective senders (reported and trusted in the Received lines) will be blocked and not the whole ISP? Don't ISPs recognize that most spam come from their subscribers whose PCs are infected by spamware without their knowledgeand acting as open relays? Orange and AT&T can both block SMTP ports from infected users, and AT&T should better seek cooperation rather than blocking the other ISPs, and especially their regular SMTP servers).
    I hate unmanaged RBLs that block entire ISPs that have set up cooperation groups and charters with other ISPs to fight spam more efficiently and more precisely (notably for very large ISPs with millions of subscribers like Orange.
    


    This archive was generated by hypermail 2.1.5 : Thu Jul 13 2006 - 20:55:19 CDT