[webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

On Mon, Jan 16, 2012 at 3:15 PM, Geoffrey Garen <ggaren at apple.com> wrote:
> I just read through the Bugzilla bugs on this topic. Hopefully, I'm a mostly neutral observer.
>
>> We should remove deprecatedFrameEncoding.  Removing the code has the
>> following benefits:
>>
>> 1) Standards compliance.
>
> To me, this seems like your strongest argument. However…
>
>>  b) Most user agents, including most browsers, do not have this
>> behavior.
>
> Is this true? In Bugzilla, I saw Alexey request cross-browser testing, but I didn't see any testing results, other than Alexey's testing of Firefox 9, which did have this behavior. So, the tested user agent compatibility score seems to be 2-1 (Safari and Firefox vs Chrome).
>
> Browser compatibility seems to be Alexey's strongest argument for not following the HTTP working group's consensus. If there were no tradeoff between the working group's consensus and browser compatibility, I suspect that Alexey's position might change.
>
> Can you supply more information here? Which web browsers have been tested, what were the tests, and what were the results?

Eric Lawrence does a good job explaining some of this history of this
topic in this blog post:

http://blogs.msdn.com/b/ieinternals/archive/2010/06/07/content-disposition-attachment-and-international-unicode-characters.aspx

Prior to RFC 5987, there was no way for servers to represent a
non-ASCII filename in the Content-Disposition header in a way that
would be interpreted consistently by user agents.  The different
interoperability camps broke down roughly as IE+Chrome and
Firefox+Safari+Opera, although even within those camps there were
inconsistencies.  What a mess!

The HTTP working group took up this issue, worked through the various
trade-offs and reached consensus around RFC 5987.  There are certainly
parts of RFC 5987 I'm not super happy about (and that I argued
against, unsuccessfully), but that's the way we can make progress on
these topics: we participate in the standards process, make
compromises, and respect the outcome.

All that being said, if you don't wish to comply with this standard at
this time, that's your choice.  I'm just asking for an ifdef so I can
turn this non-standards compliant code off in the Chromium port.

>> 2) Stability.  This code crashes.
>
> This argument seems like a red herring to me. We should make a decision about deprecatedFrameEncoding on its merits. If deprecatedFrameEncoding is the right behavior for WebKit, let's fix the crashes. If deprecatedFrameEncoding is the wrong behavior for WebKit, let's remove it. Either way, crashes aren't the deciding factor.

I don't agree that the stability of the code is a non-issue, but I'm
willing to argue point (1) first.

2012/1/16 Alexey Proskuryakov <ap at webkit.org>:
> The whole topic is quite isolated and inconsequential, so the intensity of argument (particularly in bug 67882 and its patch) does not appear adequate.

None of your email is a technical argument in response to my technical
argument.  If you feel that this issue is inconsequential, then it
shouldn't be a big deal to let me disable this code on the Chromium
port.

Adam