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

From: Dario Crivelli <[email-masked]>
Date: Wed, 16 Apr 2014 13:09:26 +0200

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 <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [hybi] New Chrome WebSocket implementation: testers wanted
> Message-ID:
>         <
> [email-masked]>
> 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
>

---

From: Adam Rice <[email-masked]>
Date: Thu, 17 Apr 2014 12:41:30 +0900

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 <[email-masked]>wrote:

> The failure seems to be related not with the WebSocket protocol itself,
> but with the failure to establish a SSL connection.
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Dario Crivelli <[email-masked]>
Date: Thu, 17 Apr 2014 09:33:54 +0200

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 <[email-masked]> wrote:

> I assume you have already instructed the browser to accept the
> certificate? Otherwise it should fail with either implementation.
>
> Thanks,
> Adam
>
>
>