Please see *webkit* (not our bugzilla) bug 67882. What is our current situation regarding this (mis)feature? It is very unclear to me. What exactly do we support regarding internationalized filenames in Content-Disposition, and how does document encoding or other things affect that processing? Bug numbers?
Thanks, Brian From: Adam Barth <[email protected]> Date: January 16, 2012 4:06 PM To: Geoffrey Garen <[email protected]> CC: [email protected] Subject: [webkit-dev] Removing deprecatedFrameEncoding On Mon, Jan 16, 2012 at 3:15 PM, Geoffrey Garen <[email protected]> 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 <[email protected]> : 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 _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev From: Geoffrey Garen <[email protected]> Date: January 16, 2012 3:15 PM To: Adam Barth <[email protected]> CC: [email protected] Subject: [webkit-dev] Removing deprecatedFrameEncoding Hi Adam. 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? 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. Best, Geoff _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
