[Webkit-unassigned] [Bug 132270] Settings::setDefaultTextEncodingName() allows to set unsupported encoding

[bugzilla-daemon at webkit.org]

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





--- Comment #3 from Darin Adler <darin at apple.com>  2014-04-28 09:34:30 PST ---
The default encoding name is only used in three places in WebCore. Before we change the rules about setting it we need to figure out what behavior we want.

For WebKit APIs there seem to be a few separate questions:

- Does an unsupported decoding name actually cause any real problems in decoding of what gets set in headers? Some uses of defaultTextEncodingName *do* handle unsupported values in a good way. It seems that TextResourceDecoder handles unsupported values, by treating unknown names as Windows Latin-1. The two other call sites don't, and that might be worth fixing. Even for supported encodings it is strange to use the encoding name string directly from settings; that skips the canonicalization that the TextEncoding class does. For example, TextEncoding will return "UTF-8", not "utf8".

- What actual decoding and encoding is done based on the unsupported decoding name? It seems clear that Windows Latin-1 is used, which seems fine to me. Maybe UTF-8 would be better in theory but on Mac and iOS at least we have the many years of the current behavior and might have apps depending on it by accident.

- Does setting the encoding do anything at all if the encoding is unsupported? Specifically, if someone calls a get function does the caller get back the unsupported encoding name? Today we support a round trip on any string, even if it's not a supported encoding.

- Can a caller tell if a given encoding is supported? Is there some way to either directly or indirectly find out if an encoding is supported?

I would like some more concrete examples of real scenarios today (on any platform) where this makes a difference. What the current behavior is and what the improved behavior would be.

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