[webkit-dev] Removing deprecatedFrameEncoding

Julian Reschke julian.reschke at gmx.de
Tue Jan 24 11:07:40 PST 2012

On 2012-01-24 19:44, Alexey Proskuryakov wrote:
> 24.01.2012, в 10:04, Julian Reschke написал(а):
>> Sorry, Alexey.
>> You did claim this is "needed for compatibility with existing content".
> Please be more careful with quotation marks. You are not quoting me, and I'm not sure what you actually refer to.

I refer to previous discussions in the related bug where you complained 
about IETF WGs ignoring requirements of browser makers. And no, I wasn't 
citing you; sorry if it looked like that.

>> But unless I'm missing something, *nobody* has complained, and Safari has been shipping with this behavior for ... how long? Months? Years? And Chrome as well?
>> Given the previous discussion we had it would be extremely useful to fully understand what's going on.
> I'm not sure what potential usefulness you have in mind. Safari behavior is designed to be interoperable and consistent. It results in correct downloaded file names for users of all live Web sites that I'm aware of (except for mail.google.com, which blacklists Safari, and wouldn't work correctly regardless of how we handled its responses).

It results in broken filenames for those sites that assume the encoding 
is ISO-8859-1.

> Perhaps there are sites that misbehave; I'd like to know about these to investigate what's going on, and potentially tweak the approach.
> It is not useful or interesting to discuss this behavior in a theoretical context where non-ASCII characters in Content-Disposition are not allowed at all.

I think, given the amount of browser quirks, we can all agree that using 
non-ASCII characters in filenames is asking for trouble. Nowadays 
servers can use an alternate syntax which is unambiguous and works 
almost in all browsers, and fall back to ASCII for the others.

What's left to do is cleanup of the browser quirks, and my understanding 
is that this is exactly what Adam intended to do. To do that, it's 
highly desirable to understand which quirks are actually needed, because 
this increases chances that browsers actually can converge on a common 
set of quirks.

I note that you're unable or unwilling to provide the information I 
asked for. That's unfortunate. My conclusion is that the "use the 
referring page's encoding" quirk isn't needed. You're welcome to prove 
me wrong.

Best regards, Julian

More information about the webkit-dev mailing list