Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-25 00:57, Alexey Proskuryakov wrote:


24.01.2012, в 15:10, Julian Reschke написал(а):


b) RFC 6266 works without UA sniffing if you're willing to serve plain ASCII to 
legacy browsers (IE<  9 and Safari)


We are talking about how to encode existing non-ASCII file names, there is no 
equivalent plain ASCII to send instead.


We had almost the same discussion over 15 months ago. I recommend you read the 
mailing list archives.


I didn't ask for this discussion to be repeated. You kept asking about the 
right thing to do, and sending UTF-8 bytes is clearly the right and forward 
looking thing to do.
...


It does not work in some of the current browsers. It will not work in 
new versions of these browsers unless their makers change their position 
on backwards compatibility. It's not an option.


So your point of view is understood, noted, but not helpful.

And yes, if we started from scratch it would be the right thing to do. 
But we aren't.


As a matter of fact, just this morning I added "fix I18N in header 
fields" to my wish list for HTTP/2.0.


Best regards, Juluab
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 15:10, Julian Reschke написал(а):

> b) RFC 6266 works without UA sniffing if you're willing to serve plain ASCII 
> to legacy browsers (IE < 9 and Safari)

We are talking about how to encode existing non-ASCII file names, there is no 
equivalent plain ASCII to send instead.

> We had almost the same discussion over 15 months ago. I recommend you read 
> the mailing list archives.

I didn't ask for this discussion to be repeated. You kept asking about the 
right thing to do, and sending UTF-8 bytes is clearly the right and forward 
looking thing to do.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-25 00:02, Alexey Proskuryakov wrote:


24.01.2012, в 14:33, Julian Reschke написал(а):


I know you don't like it but please stop spreading FUD. RFC 5987 allows senders 
to send the same thing to all clients without UA sniffing. If you have a 
different proposal for which this is true please go ahead and write it down.


What exactly am I spreading FUD about?


"has no purpose here"


That's not fear, uncertainty, or doubt.


Again, please make a proposal that is deployable and works without UA sniffing. 
I'm listening.


RFC 6266 doesn't work without UA sniffing, and even more so as we consider 
deployed browser versions, not just latest ones.


a) no proposal does work with all legacy browsers

b) RFC 6266 works without UA sniffing if you're willing to serve plain 
ASCII to legacy browsers (IE < 9 and Safari)



An authoring requirement to send UTF-8 (except for a blacklist of browsers that 
don't support it), plus a browser algorithm that matches Safari (perhaps with 
RFC 5987 style encoding added as another legacy fallback) fit the bill if 
allowed to be on equal footing with the existing request for comments.


So please head over to Microsoft and ask them to make an incompatible 
change to their behavior. Good luck with that.


We had almost the same discussion over 15 months ago. I recommend you 
read the mailing list archives.


Best regards, Julian


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 14:33, Julian Reschke написал(а):

>>> I know you don't like it but please stop spreading FUD. RFC 5987 allows 
>>> senders to send the same thing to all clients without UA sniffing. If you 
>>> have a different proposal for which this is true please go ahead and write 
>>> it down.
>> 
>> What exactly am I spreading FUD about?
> 
> "has no purpose here"

That's not fear, uncertainty, or doubt.

> Again, please make a proposal that is deployable and works without UA 
> sniffing. I'm listening.

RFC 6266 doesn't work without UA sniffing, and even more so as we consider 
deployed browser versions, not just latest ones.

An authoring requirement to send UTF-8 (except for a blacklist of browsers that 
don't support it), plus a browser algorithm that matches Safari (perhaps with 
RFC 5987 style encoding added as another legacy fallback) fit the bill if 
allowed to be on equal footing with the existing request for comments.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-24 23:28, Alexey Proskuryakov wrote:


24.01.2012, в 14:03, Julian Reschke написал(а):


Having UTF-8 Content-Disposition served by all Web sites that offer downloads 
would be the ideal outcome from higher principles. RFC 5987 style gobbledygook 
really has no purpose here, and only complicates life for implementors, site 
authors and admins alike.


RFC 5987 "gobbledygook" works in all recent browsers except the one you're 
working on. It's the only thing that currently works almost everywhere.


You chose to overlook the part about "ideal outcome" and "higher principles".

A header value that can be sent, consumed and observed (with tools like 
tcpdump) directly without turning it into unreadable gobbledygook is superior 
to one that can not be.


Yes. If it worked.


I know you don't like it but please stop spreading FUD. RFC 5987 allows senders 
to send the same thing to all clients without UA sniffing. If you have a 
different proposal for which this is true please go ahead and write it down.


What exactly am I spreading FUD about?


"has no purpose here"


We know that it works in practice.


No, it does not "work". 
See. So IE, Opera, and Konqueror 
decode as ISO-8859-1.


It works with servers and intermediaries. Internet infrastructure would not 
collapse if UTF-8 was sent in a response header.


And I never said that.

But sending UTF-8 does not work with two major browsers, so how exactly 
does it "work"?


Again, please make a proposal that is deployable and works without UA 
sniffing. I'm listening.


Best regards, Julian

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 14:03, Julian Reschke написал(а):

>> Having UTF-8 Content-Disposition served by all Web sites that offer 
>> downloads would be the ideal outcome from higher principles. RFC 5987 style 
>> gobbledygook really has no purpose here, and only complicates life for 
>> implementors, site authors and admins alike.
> 
> RFC 5987 "gobbledygook" works in all recent browsers except the one you're 
> working on. It's the only thing that currently works almost everywhere.

You chose to overlook the part about "ideal outcome" and "higher principles".

A header value that can be sent, consumed and observed (with tools like 
tcpdump) directly without turning it into unreadable gobbledygook is superior 
to one that can not be.

> I know you don't like it but please stop spreading FUD. RFC 5987 allows 
> senders to send the same thing to all clients without UA sniffing. If you 
> have a different proposal for which this is true please go ahead and write it 
> down.

What exactly am I spreading FUD about?

>> We know that it works in practice.
> 
> No, it does not "work". See 
> . So IE, Opera, and 
> Konqueror decode as ISO-8859-1.

It works with servers and intermediaries. Internet infrastructure would not 
collapse if UTF-8 was sent in a response header.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-24 22:50, Alexey Proskuryakov wrote:


24.01.2012, в 13:36, Julian Reschke написал(а):


You may be right about the default browser encoding, but I'm pretty sure you 
are not right about UTF-8.


Having UTF-8 Content-Disposition served by all Web sites that offer downloads 
would be the ideal outcome from higher principles. RFC 5987 style gobbledygook 
really has no purpose here, and only complicates life for implementors, site 
authors and admins alike.


RFC 5987 "gobbledygook" works in all recent browsers except the one 
you're working on. It's the only thing that currently works almost 
everywhere.


I know you don't like it but please stop spreading FUD. RFC 5987 allows 
senders to send the same thing to all clients without UA sniffing. If 
you have a different proposal for which this is true please go ahead and 
write it down.



We know that it works in practice.


No, it does not "work". See 
. So IE, Opera, 
and Konqueror decode as ISO-8859-1.


Best regards, Julian

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 13:36, Julian Reschke написал(а):

> You may be right about the default browser encoding, but I'm pretty sure you 
> are not right about UTF-8.

Having UTF-8 Content-Disposition served by all Web sites that offer downloads 
would be the ideal outcome from higher principles. RFC 5987 style gobbledygook 
really has no purpose here, and only complicates life for implementors, site 
authors and admins alike.

We know that it works in practice.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-24 22:29, Alexey Proskuryakov wrote:


24.01.2012, в 11:07, Julian Reschke написал(а):


My conclusion is that the "use the referring page's encoding" quirk isn't 
needed. You're welcome to prove me wrong.


I'm happy that we agree on UTF-8 and default browser encoding being needed. 
That's a huge step forward. Will this be reflected in an update to RFC 6266?


If there was agreement among the browsers that this is the case this 
could end up in an appendix.


You may be right about the default browser encoding, but I'm pretty sure 
you are not right about UTF-8.



If we don't agree on that, I don't see the point of discussing one minuscule 
detail of a design which is entirely different from the RFC.
...


It's totally not minuscule.

Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 11:07, Julian Reschke написал(а):

> My conclusion is that the "use the referring page's encoding" quirk isn't 
> needed. You're welcome to prove me wrong.

I'm happy that we agree on UTF-8 and default browser encoding being needed. 
That's a huge step forward. Will this be reflected in an update to RFC 6266?

If we don't agree on that, I don't see the point of discussing one minuscule 
detail of a design which is entirely different from the RFC.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

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.

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

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.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-24 19:00, Alexey Proskuryakov wrote:


24.01.2012, в 9:45, Julian Reschke написал(а):


Did you find out for how long this was broken? I can't even recall the last 
Safari update, insofar I have my doubts that this change affected any real 
world content.


I didn't check when exactly this broke.

As discussed earlier in this thread, waiting for complaints is not very 
practical for this kind of bugs - for multiple reason, it often takes extremely 
long time until someone files a bug.


Sorry, Alexey.

You did claim this is "needed for compatibility with existing content".

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.


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 9:45, Julian Reschke написал(а):

> Did you find out for how long this was broken? I can't even recall the last 
> Safari update, insofar I have my doubts that this change affected any real 
> world content.

I didn't check when exactly this broke.

As discussed earlier in this thread, waiting for complaints is not very 
practical for this kind of bugs - for multiple reason, it often takes extremely 
long time until someone files a bug.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-24 18:38, Alexey Proskuryakov wrote:


24.01.2012, в 02:41, Julian Reschke написал(а):


Please see.

Unless I'm testing the wrong thing (in which case I'd like to hear what's 
wrong!), it seems that neither Chrome nor Safari use the encoding of the 
referring page. At least not in this case.


This regression has been fixed yesterday, WebKit nighties should use referring 
frame encoding again.


Thanks for the update; so this *was* testing the right thing, I assume?

Did you find out for how long this was broken? I can't even recall the 
last Safari update, insofar I have my doubts that this change affected 
any real world content.


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

24.01.2012, в 02:41, Julian Reschke написал(а):

> Please see .
> 
> Unless I'm testing the wrong thing (in which case I'd like to hear what's 
> wrong!), it seems that neither Chrome nor Safari use the encoding of the 
> referring page. At least not in this case.

This regression has been fixed yesterday, WebKit nighties should use referring 
frame encoding again.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-19 02:00, Julian Reschke wrote:

...


Please see .

Unless I'm testing the wrong thing (in which case I'd like to hear 
what's wrong!), it seems that neither Chrome nor Safari use the encoding 
of the referring page. At least not in this case.


It would be great if those who claim that "this is needed for web 
compatibility" would provide feedback on the test case.


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

On Thu, Jan 19, 2012 at 1:38 PM, Geoffrey Garen  wrote:
>>> We don't typically add #ifdefs to cross-platform WebKit code solely to make 
>>> different choices about web standards and web compatibility in different 
>>> ports. (Have we ever done that before?) It strikes me as destructive to 
>>> WebKit and the web to start doing so now. I'm strongly opposed to this 
>>> option.
>>
>> Really?
>
> Yes, really.
>
>>   https://lists.webkit.org/pipermail/webkit-dev/2012-January/019105.html
>
> The URL you pasted shows Jon removing a feature that isn't used by the web 
> (not analogous to this situation), after no objection (not analogous to this 
> situation), and proposing removing it for the whole project on the same 
> grounds (consistent with the goals I've stated).

I'm not sure I understand the difference.

Anyway, thanks for taking the time to engage in this discussion.  I'm
going to write up a summary of the various points of view and propose
a path forward.

Thanks,
Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Geoffrey Garen]

>> We don't typically add #ifdefs to cross-platform WebKit code solely to make 
>> different choices about web standards and web compatibility in different 
>> ports. (Have we ever done that before?) It strikes me as destructive to 
>> WebKit and the web to start doing so now. I'm strongly opposed to this 
>> option.
> 
> Really?

Yes, really.

>   https://lists.webkit.org/pipermail/webkit-dev/2012-January/019105.html

The URL you pasted shows Jon removing a feature that isn't used by the web (not 
analogous to this situation), after no objection (not analogous to this 
situation), and proposing removing it for the whole project on the same grounds 
(consistent with the goals I've stated).

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

18.01.2012, в 17:01, Adam Barth написал(а):

>>> My understanding is that Safari, as shipping, does not use the referring 
>>> page's charset for decoding the C-D filename. Or am I missing something? So 
>>> what default is left? The client's locale?
>> 
>> Yes, someone broke that. I'm in the process of adding test coverage, and 
>> fixing the regression.
> 
> I'm curious how many users complained, if you're able to share that
> information, and which sites, if any, were adversely affected.

Julian noticed this regression, and I didn't know about it before.

Unfortunately, prior experience suggests that number of complaints is not a 
very helpful metric for internationalization bugs, for various reasons.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

2012/1/18 Julian Reschke :
> If you can write down what you think needs to be done, and can get
> Chrome/Firefox/IE/Opera on board, this may be worth documenting. I think
> that's what Adam tried ~ 15 months ago.

By the way, this my long-term goal.  My plan has been to align browser
behavior before bringing this topic back to the IETF.  That will make
it much clearer exactly what we need to document.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

2012/1/18 Alexey Proskuryakov :
> 18.01.2012, в 16:23, Julian Reschke написал(а):
>> My understanding is that Safari, as shipping, does not use the referring 
>> page's charset for decoding the C-D filename. Or am I missing something? So 
>> what default is left? The client's locale?
>
> Yes, someone broke that. I'm in the process of adding test coverage, and 
> fixing the regression.

I'm curious how many users complained, if you're able to share that
information, and which sites, if any, were adversely affected.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-19 01:42, Alexey Proskuryakov wrote:


18.01.2012, в 16:23, Julian Reschke написал(а):


It's been communicated 
(see) 
that a behavior that relies on external state won't be accepted. I don't think that 
it's fair to blame browser vendors for not working with the group on aspects that are 
pre-determined to remain incompatible.


What I said is:

"I don't think the IETF will ever approve a standard where the encoding
depends on the recipient's locale, with no reliable way to find out
upfront what that locale is."

So please don't claim I said something I did not say.


I don't see what the difference is. Anyway, the reason why I included the link 
was that everyone could see your exact words.


The difference is that I stated my personal opinion and did not make a 
statement on behalf of the IETF. Nobody can do that.


Also, let me remind you that this conversation was about "documenting" 
what browsers do *instead* of requiring support for RFC 2231. We did the 
latter, and it was the right thing to do. Today, interpreting raw bytes 
is not interoperable -- browsers differ in what they do. On the other 
hand, two more major browsers have implemented RFC 5987 (which profiles 
RFC 2231 for use in HTTP), so now out of six desktop browsers I'm 
testing with, five have support for a predictable way to use non-ASCII 
characters in filenames.



  "you need a lot of external state to process each resource"

what exactly do you mean by that?



Everything is processed in a stateful manner. The behavior of a JavaScript file 
depends on what JavaScript files were included earlier. Decoding of most 
resources depends on what the referring page encoding is. Cookies are accepted 
or not based on browser settings. One can call this orthogonal, but there is 
simply not much place for stateless thinking here.


From this list, the only thing that violates the stateless nature of 
HTTP is using out-of-band information for determining the charset. The 
other things you mentioned have nothing to do with this.


Does the HTML5 charset detection take the referrer's charset into account?


My understanding is that Safari, as shipping, does not use the referring page's 
charset for decoding the C-D filename. Or am I missing something? So what 
default is left? The client's locale?


Yes, someone broke that. I'm in the process of adding test coverage, and fixing 
the regression.


If you do that it would be cool if you found out for how long it was 
broken. In any case, this part of the algorithm doesn't seem to be very 
important if nobody noticed that it's "broken" in the shipping Safari 
version.



Besides client locale, there is UTF-8. That's actually the preferred option, 
which gets tried first. Only servers that send non-Unicode file names need out 
of band information.


How do you know for a given octet sequence whether it is UTF-8? Heuristics?

If you can write down what you think needs to be done, and can get 
Chrome/Firefox/IE/Opera on board, this may be worth documenting. I think 
that's what Adam tried ~ 15 months ago.


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

18.01.2012, в 16:23, Julian Reschke написал(а):

>> It's been communicated 
>> (see)
>>  that a behavior that relies on external state won't be accepted. I don't 
>> think that it's fair to blame browser vendors for not working with the group 
>> on aspects that are pre-determined to remain incompatible.
> 
> What I said is:
> 
> "I don't think the IETF will ever approve a standard where the encoding
> depends on the recipient's locale, with no reliable way to find out
> upfront what that locale is."
> 
> So please don't claim I said something I did not say.

I don't see what the difference is. Anyway, the reason why I included the link 
was that everyone could see your exact words.

>  "you need a lot of external state to process each resource"
> 
> what exactly do you mean by that?


Everything is processed in a stateful manner. The behavior of a JavaScript file 
depends on what JavaScript files were included earlier. Decoding of most 
resources depends on what the referring page encoding is. Cookies are accepted 
or not based on browser settings. One can call this orthogonal, but there is 
simply not much place for stateless thinking here.

> My understanding is that Safari, as shipping, does not use the referring 
> page's charset for decoding the C-D filename. Or am I missing something? So 
> what default is left? The client's locale?

Yes, someone broke that. I'm in the process of adding test coverage, and fixing 
the regression.

Besides client locale, there is UTF-8. That's actually the preferred option, 
which gets tried first. Only servers that send non-Unicode file names need out 
of band information.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-19 01:00, Alexey Proskuryakov wrote:


18.01.2012, в 15:41, Julian Reschke написал(а):


We asked browser developers to write down what *they* think is needed, and 
didn't get a proposal -- mainly because the browsers do not interoperate on 
this.


It's been communicated 
(see) 
that a behavior that relies on external state won't be accepted. I don't think that 
it's fair to blame browser vendors for not working with the group on aspects that are 
pre-determined to remain incompatible.


What I said is:

"I don't think the IETF will ever approve a standard where the encoding
depends on the recipient's locale, with no reliable way to find out
upfront what that locale is."

So please don't claim I said something I did not say. That being said: I 
firmly believe it's a bad idea to make the semantics depend on 
out-of-band information.



The way the Web looks from a browser is not stateless at all - a GET request 
can easily have side effects, you need a lot of external state to process each 
resource, and so on. It's hard to reach common ground when stateless nature is 
among the main principles of protocol design.


Please don't conflate things. Whether GET is allowed to have side 
effects is a completely orthogonal discussion.


When you say

  "you need a lot of external state to process each resource"

what exactly do you mean by that?


On the other hand, removing unreliable options reduces incompatibilities, 
untested code paths (you know what I mean), and helps developers focus on the 
variants that do work predictably.



Precisely following RFC 6266 would make it so that our users would get garbage 
in file names when downloading from sites that work fine for them today. I do 
not think that there is enough potential benefit to offset that.


My understanding is that Safari, as shipping, does not use the referring 
page's charset for decoding the C-D filename. Or am I missing something? 
So what default is left? The client's locale?


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

18.01.2012, в 15:41, Julian Reschke написал(а):

> We asked browser developers to write down what *they* think is needed, and 
> didn't get a proposal -- mainly because the browsers do not interoperate on 
> this.

It's been communicated (see 
) that 
a behavior that relies on external state won't be accepted. I don't think that 
it's fair to blame browser vendors for not working with the group on aspects 
that are pre-determined to remain incompatible.

The way the Web looks from a browser is not stateless at all - a GET request 
can easily have side effects, you need a lot of external state to process each 
resource, and so on. It's hard to reach common ground when stateless nature is 
among the main principles of protocol design.

> On the other hand, removing unreliable options reduces incompatibilities, 
> untested code paths (you know what I mean), and helps developers focus on the 
> variants that do work predictably.


Precisely following RFC 6266 would make it so that our users would get garbage 
in file names when downloading from sites that work fine for them today. I do 
not think that there is enough potential benefit to offset that.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-19 00:28, Alexey Proskuryakov wrote:


18.01.2012, в 13:02, Adam Barth написал(а):


I used to hold that opinion, but folks convinced me (and the rest of
the httpbis working group) otherwise, hence the standard.


A working group that that can be convinced to specify something so out of line 
with how browsers work is not one we should be following blindly.


We asked browser developers to write down what *they* think is needed, 
and didn't get a proposal -- mainly because the browsers do not 
interoperate on this.



It's especially so in this case, where limitations on how non-ASCII bytes are 
interpreted do not solve any problem except for formal compatibility with some 
universally ignored text in RFC 2616.


I agree that changing things over here doesn't help with any real-world 
problems, because developers will wouldn't be able to send non-ASCII 
filenames reliably (well, unless we agree on everything being UTF-8, but 
that would have broken existing content as well).


On the other hand, removing unreliable options reduces 
incompatibilities, untested code paths (you know what I mean), and helps 
developers focus on the variants that do work predictably.


Best regards, Julian

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

18.01.2012, в 13:02, Adam Barth написал(а):

> I used to hold that opinion, but folks convinced me (and the rest of
> the httpbis working group) otherwise, hence the standard.

A working group that that can be convinced to specify something so out of line 
with how browsers work is not one we should be following blindly.

It's especially so in this case, where limitations on how non-ASCII bytes are 
interpreted do not solve any problem except for formal compatibility with some 
universally ignored text in RFC 2616.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

2012/1/18 Alexey Proskuryakov :
> 18.01.2012, в 11:26, Geoffrey Garen написал(а):
>> Once again, I think the best option is to make a decision about 
>> deprecatedFrameEncoding based on its merits.
>
> Most browsers respect default encoding when parsing Content-Disposition (*), 
> which is against the letter and spirit of RFC 6266. So I think that following 
> working group consensus on one spec provision is a weak argument while 
> disobeying other ones.

I plan to fix those bugs, at least those in open source projects to
which I contribute.  (There are also bugs in how Chrome's network
stack parses the Content-Disposition header, which I also plan to
fix.)

> When we agree that non-ASCII bytes in Content-Disposition are be interpreted 
> using out of band context,

I used to hold that opinion, but folks convinced me (and the rest of
the httpbis working group) otherwise, hence the standard.

As I've written before, if you don't want to comply with this standard
at this time, that's your decision.  My complaint is that you're
forcing your decision upon other ports.  I'm just asking for the
ability to disable this non-standards complaint code.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-18 21:11, Alexey Proskuryakov wrote:


18.01.2012, в 11:26, Geoffrey Garen написал(а):


Once again, I think the best option is to make a decision about 
deprecatedFrameEncoding based on its merits.


Most browsers respect default encoding when parsing Content-Disposition (*), 
which is against the letter and spirit of RFC 6266. So I think that following 
working group consensus on one spec provision is a weak argument while 
disobeying other ones.


RFC 6266 is mainly concerned with defining something that will always 
and reliably work. This is helpful for content providers, not browser 
developers, agreed. The solution is to use RFC2231/5987 encoding. I know 
you don't want to discuss this here, but anyway: Safari is the only 
browser left not supporting it, and the fact it does not still forces 
content authors to special-case responses based on the user agent. 
(Well, similarly to legacy IEs)


RFC 6266 is not in the position to override RFC 2616. HTTPbis is, and 
already is very clear in that non-ASCII characters in header fields are 
unreliable, and what you posted below confirms that.


Are you aware of any *other* header fields that get this treatment? (I'm 
asking because it would affect where we would put additional warnings 
into the specs). Maybe WWW-Authenticate's realm parameter?



When we agree that non-ASCII bytes in Content-Disposition are be interpreted 
using out of band context, I find it quite obvious that referring frame 
encoding is the best piece of context we have. It's what used for subframe 
default encoding as well, so ignoring it just for file names would be 
inconsistent.

*) Tested a direct download of a file.
IE 9: Respects default encoding that depends on system language.
Safari 5.1.2: Respects default encoding that is configurable in preferences.
Chrome 16.0.912.75: Respects default encoding - not sure if it's manually 
configurable, but it's Windows-1251 (Cyrillic) on my machine.
Firefox 9.0.1: Does not appear to respect default encoding (but then it of 
course respects referring frame encoding).
Opera 11.60: Respects default encoding, but buggy for Russian primary language, 
picking a different encoding than what is used for page content (ISO-8859-5 
instead of Windows-1251).
...


Using the system encoding doesn't really help if you don't know the 
default encoding of the recipient.


Using the referring page's encoding doesn't help if you access the link 
from different referring pages, or even from somewhere else (like 
clicking on a link in your mail client).


The list of test results above shows that picking an encoding based on 
out-of-band information is not reliable. It may give acceptable results 
in certain cases, but, for instance, wouldn't be useful for a site that 
needs to work globally (think GMail).


Best regards, Julian
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

18.01.2012, в 11:26, Geoffrey Garen написал(а):

> Once again, I think the best option is to make a decision about 
> deprecatedFrameEncoding based on its merits.

Most browsers respect default encoding when parsing Content-Disposition (*), 
which is against the letter and spirit of RFC 6266. So I think that following 
working group consensus on one spec provision is a weak argument while 
disobeying other ones.

When we agree that non-ASCII bytes in Content-Disposition are be interpreted 
using out of band context, I find it quite obvious that referring frame 
encoding is the best piece of context we have. It's what used for subframe 
default encoding as well, so ignoring it just for file names would be 
inconsistent.

*) Tested a direct download of a file.
IE 9: Respects default encoding that depends on system language.
Safari 5.1.2: Respects default encoding that is configurable in preferences.
Chrome 16.0.912.75: Respects default encoding - not sure if it's manually 
configurable, but it's Windows-1251 (Cyrillic) on my machine.
Firefox 9.0.1: Does not appear to respect default encoding (but then it of 
course respects referring frame encoding).
Opera 11.60: Respects default encoding, but buggy for Russian primary language, 
picking a different encoding than what is used for page content (ISO-8859-5 
instead of Windows-1251).

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

On Wed, Jan 18, 2012 at 11:26 AM, Geoffrey Garen  wrote:
>> 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.
>
> We don't typically add #ifdefs to cross-platform WebKit code solely to make 
> different choices about web standards and web compatibility in different 
> ports. (Have we ever done that before?) It strikes me as destructive to 
> WebKit and the web to start doing so now. I'm strongly opposed to this option.

Really?  https://lists.webkit.org/pipermail/webkit-dev/2012-January/019105.html

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Geoffrey Garen]

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

We don't typically add #ifdefs to cross-platform WebKit code solely to make 
different choices about web standards and web compatibility in different ports. 
(Have we ever done that before?) It strikes me as destructive to WebKit and the 
web to start doing so now. I'm strongly opposed to this option.

Once again, I think the best option is to make a decision about 
deprecatedFrameEncoding based on its merits.

Geoff
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

16.01.2012, в 16:24, Julian Reschke написал(а):

> But we should keep in mind that what's much more important here is to 
> actually provide developers with a protocol/format that is interoperable for 
> non-ASCII. I note that Safari is the only current browser which doesn't 
> implement RFC 5987 (*). Enough said.

RFC 5987 support would be outside of open source WebKit for Safari, and is thus 
off topic for this list.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [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  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:

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
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Julian Reschke]

On 2012-01-17 00:57, Alexey Proskuryakov wrote:


16.01.2012, в 15:15, Geoffrey Garen написал(а):


1) Standards compliance.


To me, this seems like your strongest argument. However…


I'm pretty sure that no major browser implements - or maybe even intends to 
implement - all encoding-related aspects of RFC 6266. For example, Chrome uses 
default encoding instead of US-ASCII to interpret Content-Disposition bytes. 
This is clearly a case of using external context to interpret the response, and 
a violation of letter and spirit of the spec.


RFC 6266 doesn't mandate US-ASCII here. It defaults to what HTTP/1.1 
defaults to, and that is ISO-8859-1.


According to , all 
UAs do that in absence of out-of-band information, and given a valid 
ISO-8859-1 octet sequence that doesn't look like UTF-8.


Now I'm the first one to agree that ISO-8859-1 was a bad choice as 
default. It's for historical reasons. Blame those who worked on the 
specs in 90s.



There is a long history of HTTP related specs disregarding browser needs when 
it comes to non-ASCII characters in headers fields, or to stateful 
interpretation of responses.


"There's a long history of browser makers ignoring the standards process 
and writing crappy implementations".


Not productive.

If you don't like where the specs are headed, provide feedback to the 
Working Groups producing them.



This is a discussion that we had before, including on this list. I don't think 
that enough has changed to make spending time on this again very useful. The 
whole topic is quite isolated and inconsequential, so the intensity of argument 
(particularly in bug 67882 and its patch) does not appear adequate.


I support Adam in his proposal to clean up the mess. But we should keep 
in mind that what's much more important here is to actually provide 
developers with a protocol/format that is interoperable for non-ASCII. I 
note that Safari is the only current browser which doesn't implement RFC 
5987 (*). Enough said.


Best regards, Julian

(*) IE9 only supports UTF-8, but see 


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

On Mon, Jan 16, 2012 at 3:15 PM, Geoffrey Garen  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 :
> 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
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Alexey Proskuryakov]

16.01.2012, в 15:15, Geoffrey Garen написал(а):

>> 1) Standards compliance.
> 
> To me, this seems like your strongest argument. However…

I'm pretty sure that no major browser implements - or maybe even intends to 
implement - all encoding-related aspects of RFC 6266. For example, Chrome uses 
default encoding instead of US-ASCII to interpret Content-Disposition bytes. 
This is clearly a case of using external context to interpret the response, and 
a violation of letter and spirit of the spec.

There is a long history of HTTP related specs disregarding browser needs when 
it comes to non-ASCII characters in headers fields, or to stateful 
interpretation of responses.

This is a discussion that we had before, including on this list. I don't think 
that enough has changed to make spending time on this again very useful. The 
whole topic is quite isolated and inconsequential, so the intensity of argument 
(particularly in bug 67882 and its patch) does not appear adequate.

- WBR, Alexey Proskuryakov

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Geoffrey Garen]

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
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Removing deprecatedFrameEncoding

[Jochen Eisinger]

On Sun, Jan 15, 2012 at 9:52 PM, Adam Barth  wrote:

> We've previously discussed this topic in Bug 67882 and Bug 75905.
>
> We should remove deprecatedFrameEncoding.  Removing the code has the
> following benefits:
>
> 1) Standards compliance.  There was a discussion in the HTTP working
> group about whether the requesting context should be a factor in
> determining the character set used to decode the Content-Disposition
> header.  The working group decided that we shouldn't use that
> information for several reasons:
>
>  a) Varying the interpretation of an HTTP response based on the
> context of the request is contrary to the stateless nature of HTTP.
> The fact that HTTP request/response pairs can be understood
> irrespective of context is core to the design of HTTP.
>
>  b) Most user agents, including most browsers, do not have this
> behavior.  That means the compatibility risk for dropping the behavior
> in other user agents (e.g., Safari) is relatively low, especially for
> a feature likes this one that is not widely used on the mobile web.
>
> 2) Stability.  This code crashes.  For example, in the most recent
> release of Chrome Canary on Windows, deprecatedFrameEncoding accounts
> for 3.5% of all renderer crashes.  While we could invest effort in
> fixing these crashes, we'd be better off removing this code and
> spending that effort improving stability elsewhere.
>

For the sake of completeness: The crashes I've seen end in

[DocumentWriter.cpp:246] WebCore::DocumentWriter::deprecatedFrameEncoding()
[FrameLoader.cpp:2591] WebCore::FrameLoader::addExtraFieldsToRequest()
[FrameLoader.cpp:1191] WebCore::FrameLoader::loadURL()

implying that the FrameLoader doesn't have an active document loader at
that point.

-jochen



> If removing deprecatedFrameEncoding isn't possible at this time, we
> should revert http://trac.webkit.org/changeset/104723 because it
> causes crashes.  Rather than get into a revert war, however, I believe
> the project would be better served by talking out this issue.
>
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] Removing deprecatedFrameEncoding

[Adam Barth]

We've previously discussed this topic in Bug 67882 and Bug 75905.

We should remove deprecatedFrameEncoding.  Removing the code has the
following benefits:

1) Standards compliance.  There was a discussion in the HTTP working
group about whether the requesting context should be a factor in
determining the character set used to decode the Content-Disposition
header.  The working group decided that we shouldn't use that
information for several reasons:

  a) Varying the interpretation of an HTTP response based on the
context of the request is contrary to the stateless nature of HTTP.
The fact that HTTP request/response pairs can be understood
irrespective of context is core to the design of HTTP.

  b) Most user agents, including most browsers, do not have this
behavior.  That means the compatibility risk for dropping the behavior
in other user agents (e.g., Safari) is relatively low, especially for
a feature likes this one that is not widely used on the mobile web.

2) Stability.  This code crashes.  For example, in the most recent
release of Chrome Canary on Windows, deprecatedFrameEncoding accounts
for 3.5% of all renderer crashes.  While we could invest effort in
fixing these crashes, we'd be better off removing this code and
spending that effort improving stability elsewhere.

If removing deprecatedFrameEncoding isn't possible at this time, we
should revert http://trac.webkit.org/changeset/104723 because it
causes crashes.  Rather than get into a revert war, however, I believe
the project would be better served by talking out this issue.

Adam
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev