Re: [hybi] New Chrome WebSocket implementation: testers wanted

Sorry for the delay in responding. This turned out to be more complicated
than I expected, but the fix landed on Chromium trunk yesterday (
https://codereview.chromium.org/304093003 ). It should be available in a
dev build some time soon.

On 17 April 2014 16:33, Dario Crivelli <dario.crivelli@lightstreamer.com>
wrote:

> Yes, Adam.
> And this is furtherly confirmed by the fact that from the viewpoint of my
> server (which leverages Java's SSLEngine) the handskake completes
> successfully and only when the server waits for a request to come is the
> socket broken.
> Then, for some reason, Chrome seems to recover when it has to do a normal
> https request, whereas it doesn't when it has to do a wss interaction.
> I can try to provide you with more details; please advise if I can keep
> doing that legitimately through this mailing list.
>
> Dario
>
>
>
>
> On Thu, Apr 17, 2014 at 5:41 AM, Adam Rice <ricea@google.com> wrote:
>
>> Dario,
>>
>> Thank you for the feedback. I will check this scenario.
>>
>> I assume you have already instructed the browser to accept the
>> certificate? Otherwise it should fail with either implementation.
>>
>> Thanks,
>> Adam
>>
>>
>>
>> On 16 April 2014 20:09, Dario Crivelli <dario.crivelli@lightstreamer.com>
>> wrote:
>>
>>> Hi Adam,
>>>
>>> We have tried the extended version of Chrome against our Lightstreamer
>>> Server and we have noticed that, with the new implementation enabled, the
>>> browser can't open a WebSocket towards Lightstreamer Server in the
>>> following conditions:
>>> - wss: is used
>>> - the server certificate is self-signed
>>> (on the other hand, when using either plain ws: or a valid certificate
>>> we found no issue).
>>>
>>> The failure seems to be related not with the WebSocket protocol itself,
>>> but with the failure to establish a SSL connection.
>>> However, the same does not happen with the new implementation disabled.
>>>
>>> In particular, we have noticed small differences in the way the browser
>>> opens the sockets for SSL.
>>> When the certificate is self-signed, the browser sometimes seems to need
>>> two attempts in order to establish a connection:
>>> in the first attempt, the handshake succeeds but, after that, the
>>> browser immediately closes the socket;
>>> then the second attempt succeeds fully.
>>> We see the above pattern also when the new implementation is not
>>> enabled, but when it is enabled we see more occurrences of the pattern and
>>> this seems correlated with the failure in WebSocket establishment.
>>>
>>> Dario Crivelli
>>>
>>>
>>>
>>>> Message: 1
>>>> Date: Tue, 15 Apr 2014 15:11:49 +0900
>>>> From: Adam Rice <ricea@google.com>
>>>> To: "hybi@ietf.org" <hybi@ietf.org>
>>>> Subject: [hybi] New Chrome WebSocket implementation: testers wanted
>>>> Message-ID:
>>>>         <
>>>> CAHixhFrA2FH6JOOFkd9sjBtgvBKEO6CZ9K9T-NdKf8PvXTiG2A@mail.gmail.com>
>>>> Content-Type: text/plain; charset="utf-8"
>>>>
>>>>
>>>> The latest dev build of Chrome includes a new WebSocket implementation
>>>> behind an experimental flag. If you have version 36.0.1933.0 or greater,
>>>> you can enable it using the "Enable experimental Web Platform features"
>>>> flag in about:flags.
>>>>
>>>> An easy way to distinguish the different implementations is that the
>>>> stable
>>>> implementation does not set the "Accept-Language:" header, whereas the
>>>> new
>>>> implementation does. You can examine the headers by opening the Network
>>>> panel in "Developer Tools" before creating the WebSocket connection.
>>>>
>>>> A known issue with the new implementation is that RFC6455 connection
>>>> throttling is not implemented yet. This will be done Real Soon Now.
>>>>
>>>> We are interested in hearing about any compatibility problems you might
>>>> encounter, either server side or in client libraries.
>>>>
>>>> Feedback welcome.
>>>>
>>>> Adam Rice
>>>>
>>>
>>>
>>> _______________________________________________
>>> hybi mailing list
>>> hybi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/hybi
>>>
>>>
>>
>