We've previously discussed this topic in Bug 67882 and Bug 75905. We should remove deprecatedFrameEncoding. Removing the code has the following benefits:
1) Standards compliance. There was a discussion in the HTTP working group about whether the requesting context should be a factor in determining the character set used to decode the Content-Disposition header. The working group decided that we shouldn't use that information for several reasons: a) Varying the interpretation of an HTTP response based on the context of the request is contrary to the stateless nature of HTTP. The fact that HTTP request/response pairs can be understood irrespective of context is core to the design of HTTP. b) Most user agents, including most browsers, do not have this behavior. That means the compatibility risk for dropping the behavior in other user agents (e.g., Safari) is relatively low, especially for a feature likes this one that is not widely used on the mobile web. 2) Stability. This code crashes. For example, in the most recent release of Chrome Canary on Windows, deprecatedFrameEncoding accounts for 3.5% of all renderer crashes. While we could invest effort in fixing these crashes, we'd be better off removing this code and spending that effort improving stability elsewhere. If removing deprecatedFrameEncoding isn't possible at this time, we should revert http://trac.webkit.org/changeset/104723 because it causes crashes. Rather than get into a revert war, however, I believe the project would be better served by talking out this issue. Adam _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
