[webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-17 01:06, Adam Barth wrote:
> 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!

Almost. RFC 5987 is a tiny revision of RFC 2231, and Firefox, Opera and 
Konqueror have been implemented this for many many years. So the only 
UAs missing where IE (fixed in IE9), Chrome (fixed in Chrome ~9), and 
Safari (not fixed).

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

Thanks.

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

Out of curiosity: which part of the stack does this belong to? I'm a bit 
confused because Chrome does implement RFC 5987, and apparently that's 
not in the Webkit code. Maybe the simple answer is to fork the code for 
Content-Disposition, and move everything you need into Chrome?

Best regards, Julian