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

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