[webkit-dev] Removing deprecatedFrameEncoding
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
> 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
Best regards, Julian
More information about the webkit-dev