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

Dario Crivelli <> Wed, 16 April 2014 11:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7196E1A013A for <>; Wed, 16 Apr 2014 04:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.922
X-Spam-Level: *
X-Spam-Status: No, score=1.922 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_55=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yD53zAaP3jJD for <>; Wed, 16 Apr 2014 04:09:52 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::231]) by (Postfix) with ESMTP id 54B7E1A0137 for <>; Wed, 16 Apr 2014 04:09:51 -0700 (PDT)
Received: by with SMTP id u57so10549976wes.22 for <>; Wed, 16 Apr 2014 04:09:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=SZfJcMvoAQ84v0lIuF1dD6lAJUXnCiaaFTzdLRmluZA=; b=ACLXJLt+hNHvbRanlDQBY44IapJvZ8a0qhHtvW7B9mLcx4OQS6gUq5aiGV9CLs3ZYc onbavCGeSG0SNrP3bTXZE+gbXiVHPxxNNQ/hoElu7+KWy58j09XeYTtP+0qrcWHomA5p 0lrb0ARHh7AfYOGBPp3wU6gWWnmLmChctv2vw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-type; bh=SZfJcMvoAQ84v0lIuF1dD6lAJUXnCiaaFTzdLRmluZA=; b=GnSqBNkBDz4JAevqRlgW/KvxhQ0bpr7uVpQNKZ9EFsVMpddJLEWCpWcF8vXwyCQz6P f3/14bZwC3/ylEWnqca7SoMv/6Zsk3cYG6OKOt2kRjHzN6NIhJ25yaTnBh7RlDYkaEPs 0Wxp085ctNup94LPxqquPli090KZG9GrDXZXgrlbdCv0KMwTcN5gFEY+I9ctE//fAKIO o/B0BkHvhdFwFdCvedAAnDU1OwhqgyZQvt3dqx4qJsFJfwIdDCNfsL7n17Irpz0GSDBK 7v7e/V77Df5LmprVZF9vhHbp2+ZuVrJBqZ6xuaYtEVmljdfBiwhYZRDBc8Bqyjwly+L/ ZPtw==
X-Gm-Message-State: ALoCoQnCdMd/w4IgUZ8ELsz4NL8sThSrpbKXJjYV1nfSeFkxc1fmLlaAP2U8ZI32G4JRvEYFRwXR
X-Received: by with SMTP id dq2mr7006030wib.54.1397646587808; Wed, 16 Apr 2014 04:09:47 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 16 Apr 2014 04:09:26 -0700 (PDT)
X-Originating-IP: []
From: Dario Crivelli <>
Date: Wed, 16 Apr 2014 13:09:26 +0200
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary=f46d044480616367cf04f726f435
Subject: Re: [hybi] New Chrome WebSocket implementation: testers wanted
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Apr 2014 11:09:56 -0000

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