[Webkit-unassigned] [Bug 66084] XML parser doesn't emit Fatal Error when HTTP charset=foo conflicts with BOM

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66084


Leif Halvard Silli <xn--mlform-iua at xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|The XML parser doesn't      |XML parser doesn't emit
                   |ignore the BOM when HTTP    |Fatal Error when HTTP
                   |Content-Type: charset=foo   |charset=foo conflicts with
                   |conflicts with it           |BOM




--- Comment #2 from Leif Halvard Silli <xn--mlform-iua at xn--mlform-iua.no>  2011-08-13 13:37:56 PST ---
(In reply to comment #1)
> A BOM is most authoritative indication of encoding, because there are few ways to get it wrong. It's much easier to get an encoding declaration or an HTTP header wrong.
> 
> There are some synthetic examples of strings in other encodings that can be mistaken for a BOM, but it hasn't been a practical issue.

I see your point.

But if this is Webkit's position, then I recomend to state this in W3_bug_12897 (<http://www.w3.org/Bugs/Public/show_bug.cgi?id=12897>) and to also file a bug against XML 1.0!

Alternatively, Webkit's XML parser could remove support for all encodings except for those for which XML 1.0 requires support: UTF-8 and UTF-16. Then you could support, at least *those* encodings correctly!

IMHO, a valid reason to not listen to Webkit, if you should want to change HTML5 and XML 1.0 to behave like Webkit currently behaves w.r.t. HTTP and the BOM, is that Webkit have so many errors  when it comes to encodings in XML files: You do not properly treat UTF-8 as the default encoding and you do almost never emit fatal error (see the other bugs I filed recently). 

Thus, to support your position on the BOM when HTTP conflicts with it, would be to simultaneously silently support the way Webkit in general treats encodings for XML files. It would be to "cave in" to Webkit's current possition, which seems to be that 

  a) encodings in XML and HTML should behave the same way - the HTML way
  b) there is no real encoding default for XML files, except when there is a BOM

To add a point c)

  c) always adhere to HTTP  except when there is a BOM

beomes too much, I am afraid. May be c) is useful - I am seriously considering that it is! (See the W3C bug I pointed to above.) But unless Webkit properly support the rest of the encodings rules, then at least Webkit's position does not sound very credible to me.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.