[webkit-dev] Removing deprecatedFrameEncoding

[Jochen Eisinger]

On Sun, Jan 15, 2012 at 9:52 PM, Adam Barth <abarth at webkit.org> wrote:

> 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.
>

For the sake of completeness: The crashes I've seen end in

[DocumentWriter.cpp:246] WebCore::DocumentWriter::deprecatedFrameEncoding()
[FrameLoader.cpp:2591] WebCore::FrameLoader::addExtraFieldsToRequest()
[FrameLoader.cpp:1191] WebCore::FrameLoader::loadURL()

implying that the FrameLoader doesn't have an active document loader at
that point.

-jochen



> 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
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120116/9a8b1d2f/attachment.html>