From nobody Mon Apr 14 23:11:56 2014 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1C11A04B6 for ; Mon, 14 Apr 2014 23:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.65 X-Spam-Level: * X-Spam-Status: No, score=1.65 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, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfDt_R45OALg for ; Mon, 14 Apr 2014 23:11:52 -0700 (PDT) Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) by ietfa.amsl.com (Postfix) with ESMTP id E0AF91A008B for ; Mon, 14 Apr 2014 23:11:51 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id i7so10433740oag.9 for ; Mon, 14 Apr 2014 23:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=mUUOeOwWm+juQtlsq2gG6UT/eylKI94bSwS+Jdsisoo=; b=XDutaMZGvtdOo293e9bgNTSY/A3+TQx6EQcABIa8cTIwYI/F1NtXDcyZJ4Pc+prGSf D0qr2q/GPK4RPIT+xWy1re1GtbOgM0ohhieuWltBhjo9DhRoEN36biznXxgHpVe9iRe/ wLkoG2pCziULBFRtf0qnWnRJofQk58yu2gcIWAGA43drKXObN6+7oMFQ5rDi9r2UREU9 X8ccDGZzpd9TmScF7mWDOzS0qGRWe9k7VWtY34ETOQFtP8jj7b67HCyrHbYk46wCgTV0 zxBLaEtQUfxHxwquMi7xSHmoQowlhG5APB1rqpyvgNau12RHMCTjesD8/qOXG1/0afFd zPtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=mUUOeOwWm+juQtlsq2gG6UT/eylKI94bSwS+Jdsisoo=; b=KyyEZInm2YHLNqo0deJ0yPceJDU28SggEu5HDAwsIYhCiwGvMNT54+BuQsJB6U5oyJ SgWxJhHdXmPIHWjg3EPTZoZCUcClG3eoqs+ytgiUZuz/2cLMPClQxCv9AHRtxy/iwRCb 0OtGRRSaCmgbOtWUuCUMgwJl5Rwh8z2JUHgcOwjXD5EcRRg2FhDgr7YmnDpzhm5grNWy Ibegr9RLXzwndYOiy9bJg3lJGUt3w8XukKA+vlNK/I9hX90TUQPbjZo1Y3s2YDkEfADZ OpyV89ZGEXxkyL2gJ7/za7LlQwxxqVyM9+ZxTfXC8BZz1M0CIymd+wc6yDs4WLa78DPe XHvA== X-Gm-Message-State: ALoCoQk8k3XvVSvA8MTox9knJ3PE/tQ66pkY9xUfIyEOZxrNGcnuzgv2xaN8mtg8cF+5h6azQU6Anj5iKKEpBbhtJuFFMUFuayU1nT8fli0PBH+R4QA9TXJivjJVZtuzzYKqC3yPlj5qqUy6Kw1Zg8a7gRrCG0lDQpgGywZlBD2nactZjGw5qclUIONGZ2bx6rhAoUNz5MNg MIME-Version: 1.0 X-Received: by 10.182.225.163 with SMTP id rl3mr12593obc.79.1397542309066; Mon, 14 Apr 2014 23:11:49 -0700 (PDT) Received: by 10.182.76.167 with HTTP; Mon, 14 Apr 2014 23:11:49 -0700 (PDT) Date: Tue, 15 Apr 2014 15:11:49 +0900 Message-ID: From: Adam Rice To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2e672e41f4604f70eac93 Archived-At: http://mailarchive.ietf.org/arch/msg/hybi/dW4qcsyuBOA9UdxgslVVa69yBeo Subject: [hybi] New Chrome WebSocket implementation: testers wanted X-BeenThere: hybi@ietf.org 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: Tue, 15 Apr 2014 06:11:53 -0000 --001a11c2e672e41f4604f70eac93 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 --001a11c2e672e41f4604f70eac93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The latest dev build of Chrome includes a new WebSocket im= plementation behind an experimental flag. If you have version 36.0.1933.0 o= r greater, you can enable it using the "Enable experimental Web Platfo= rm 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 RFC64= 55 connection throttling is not implemented yet. This will be done Real Soo= n Now.

We are interested in hearing about any comp= atibility problems you might encounter, either server side or in client lib= raries.

Feedback welcome.

Adam Rice
--001a11c2e672e41f4604f70eac93-- From nobody Wed Apr 16 04:09:59 2014 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7196E1A013A for ; Wed, 16 Apr 2014 04:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yD53zAaP3jJD for ; Wed, 16 Apr 2014 04:09:52 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 54B7E1A0137 for ; Wed, 16 Apr 2014 04:09:51 -0700 (PDT) Received: by mail-we0-f177.google.com 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; d=lightstreamer.com; 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; d=1e100.net; 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 10.180.96.66 with SMTP id dq2mr7006030wib.54.1397646587808; Wed, 16 Apr 2014 04:09:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.106.38 with HTTP; Wed, 16 Apr 2014 04:09:26 -0700 (PDT) X-Originating-IP: [2.238.52.66] From: Dario Crivelli Date: Wed, 16 Apr 2014 13:09:26 +0200 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=f46d044480616367cf04f726f435 Archived-At: http://mailarchive.ietf.org/arch/msg/hybi/l-d_FLG6Jm8L48wZ9dJ6pUxtGRA Subject: Re: [hybi] New Chrome WebSocket implementation: testers wanted X-BeenThere: hybi@ietf.org 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 --f46d044480616367cf04f726f435 Content-Type: text/plain; charset=ISO-8859-1 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: "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 > --f46d044480616367cf04f726f435 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adam,

We have tried the extended ver= sion of Chrome against our Lightstreamer Server and we have noticed that, w= ith 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 relat= ed not with the WebSocket protocol itself, but with the failure to establis= h 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 certi= ficate 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 i= mmediately closes the socket;
then the second attempt succeeds fu= lly.
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:
=A0 =A0 =A0 =A0 <CAHixhFrA2FH6JOOFkd9sjBtgvBKEO6CZ9K9T-NdKf8P= vXTiG2A@mail.gmail.com>
Content-Type: text/plain; charset=3D"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, wherea= s the new
implementation does. You can examine the headers by opening the Network
panel in "Developer Tools" before creating the WebSocket connecti= on.

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
=A0
--f46d044480616367cf04f726f435-- From nobody Wed Apr 16 20:41:42 2014 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D306A1A0438 for ; Wed, 16 Apr 2014 20:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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, RP_MATCHES_RCVD=-0.272, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iDHvSI4SjPTJ for ; Wed, 16 Apr 2014 20:41:34 -0700 (PDT) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 275161A0433 for ; Wed, 16 Apr 2014 20:41:33 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so13531038obc.29 for ; Wed, 16 Apr 2014 20:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jTk4UDYh5jebsgmQRZ4n896tQWIgQsUjcykLHmDcoTE=; b=KDUU+yugODsWEo+j/01dlhF9td4/iEHF0b0oID3cXwk3+7Q/fl49msE5EzxYfH6pTP RTZNlqGa9sB9PjUvZGsR66PxOdVlpf1A/2g7pDeqCNQ678ZK8514va429uGk4NuZhcsP QgcTgjrFJw6bWgBTI+vDvS7lJAq5F+wFa55cxm2LsmKhZOSer3MD3SxneX40GG+mO8+B crsnPziBxGDpcIRDSuJgJHVJNrMQHyQgT2fQpW+iP8eF3imUEiAhHn0KanUwB+sdmIOU 2RY3BLnFaukVmSTyhOC1F52+7jFwXyZcZHQljRVeNChhDcKArWdinfQ0FWYrfIOpcbrp DKcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=jTk4UDYh5jebsgmQRZ4n896tQWIgQsUjcykLHmDcoTE=; b=jyM2kPTihLjHOB1ksTuWBNQ84g+bUe4cjtqsIJhdfmF+HoXaay69XLC4H8Mo31gVcX 3MVJ1jFnJF11/rIOdHnHwQJg9XDrYpI7DdPbwi2tn5Me+K+PtFFZlbtWybKi6+NVYlGG 2Ispm/Lf7hBKH4KHQ44e1di/lM7Y0lVZIFXq3sGJg5hC/M3fNEqU/0jjgaXCvIuvLsgp N63rKx3zj5lXTTNyhXvz6vYKn8UcfQKTc8X5c4P0sUTIuG9pAAHxGzMapb0jYVrtJnpb SrGiop+vifdZ0cJjGORknKY0FiE/jw4y85Ketzp9iWp7bVCqq5R3TeVKuXnW5pfwbf5k mvuA== X-Gm-Message-State: ALoCoQmfriv9pJOIfXu23vWOgaKUIg47Seo//5kh6+A53PHAsXLUQC1OJAc32Qx1mmYoBTpHD4OAD/cqu5sKBbyykgAWNxp5TRbjskLqYsM02HMcLyHg4nehAKD+CyjjBOI0OgoPj2bZdZVCB4Row37gOFXcwaeS+mg4FN3o3BCUT+Znq6vtoHDdSRc1D6n1pRykaRrdG2Yy MIME-Version: 1.0 X-Received: by 10.182.153.226 with SMTP id vj2mr9926046obb.26.1397706090460; Wed, 16 Apr 2014 20:41:30 -0700 (PDT) Received: by 10.182.76.167 with HTTP; Wed, 16 Apr 2014 20:41:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 17 Apr 2014 12:41:30 +0900 Message-ID: From: Adam Rice To: Dario Crivelli Content-Type: multipart/alternative; boundary=089e013d0dc005d41404f734cff3 Archived-At: http://mailarchive.ietf.org/arch/msg/hybi/pH9rf2J0FOOWSujywY1sQcAzeXU Cc: "hybi@ietf.org" Subject: Re: [hybi] New Chrome WebSocket implementation: testers wanted X-BeenThere: hybi@ietf.org 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: Thu, 17 Apr 2014 03:41:42 -0000 --089e013d0dc005d41404f734cff3 Content-Type: text/plain; charset=UTF-8 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 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 >> To: "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 > > --089e013d0dc005d41404f734cff3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dario,

Thank you for the feedback. I wi= ll 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&g= t; wrote:
Hi Adam,

We have tried the extended version of Chrome against our Lightstreamer Ser= ver and we have noticed that, with the new implementation enabled, the brow= ser can't open a WebSocket towards Lightstreamer Server in the followin= g 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 relat= ed not with the WebSocket protocol itself, but with the failure to establis= h 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 certi= ficate 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 i= mmediately closes the socket;
then the second attempt succeeds fu= lly.
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 <r= icea@google.com>
To: "hybi@ietf.org<= /a>" <hybi@ietf.= org>
Subject: [hybi] New Chrome WebSocket implementation: testers wanted
Message-ID:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <CAHixhFrA2FH6J= OOFkd9sjBtgvBKEO6CZ9K9T-NdKf8PvXTiG2A@mail.gmail.com>
Content-Type: text/plain; charset=3D"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, wherea= s the new
implementation does. You can examine the headers by opening the Network
panel in "Developer Tools" before creating the WebSocket connecti= on.

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
=C2=A0

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--089e013d0dc005d41404f734cff3-- From nobody Thu Apr 17 00:34:26 2014 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4940B1A006D for ; Thu, 17 Apr 2014 00:34:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.121 X-Spam-Level: * X-Spam-Status: No, score=1.121 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEUFzaoGGAVa for ; Thu, 17 Apr 2014 00:34:19 -0700 (PDT) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id 34C651A0149 for ; Thu, 17 Apr 2014 00:34:18 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so75921wgh.10 for ; Thu, 17 Apr 2014 00:34:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightstreamer.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0jEdAmlK+s75mms6gfKg/hO1hxJCeRwcVKu4OZ7YbVc=; b=fbJ1GaFZecw1qKLkQ6sd7nqQtws0ndiQrAZMrfIVxhYQtZq1e/aci+VrROzFvq/VUo X9U+gpW+Pjj7aseBOsBT3KDdWKNu7eABps9DStNGyRuZVaHfpVzhd1WLFd84jpgRIk6h TemV5t3oOiF1WajHUDUucMXVUZg8Cw89BOJxQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0jEdAmlK+s75mms6gfKg/hO1hxJCeRwcVKu4OZ7YbVc=; b=K/gaomBX8Te6H5ryJdXqtUF69LADZ+Nz88Nv67th9rWedBqO8TqH014y9QAcZhMy/0 KU7ptFGeAU3dTFBJfq+U7q/PRRqxqjcYGzR/Rl3Rs938dt0glzvM0AO8CT2VPL2F8fJo 5u3k8hv3xrgmRjh03pgHWSz/DKh7Vmu4B4DoEFaUG2mKL3Xr6R1s18W1myDH3k8Xi68h NID1hJ3x6yeWra4zGWWulyLvvcnAmsH+/sGmY0gEGcBsrWAUDaQG2rHb1oVht121RER5 35u2fc5+vAoafDCjprOaEIY6Kg8j4MlDVVW/RrEjKHbCvkzuO4+6b5DhboprEeZ1wo1U f2ag== X-Gm-Message-State: ALoCoQkCWhFXOpVCiqimYZErX9RzqAbveIOdbKNT0XJra6qK2NhozaYZld57fpNYJUo43kAv7WqJ X-Received: by 10.180.80.232 with SMTP id u8mr22922959wix.13.1397720054966; Thu, 17 Apr 2014 00:34:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.106.38 with HTTP; Thu, 17 Apr 2014 00:33:54 -0700 (PDT) X-Originating-IP: [2.238.52.66] In-Reply-To: References: From: Dario Crivelli Date: Thu, 17 Apr 2014 09:33:54 +0200 Message-ID: To: Adam Rice Content-Type: multipart/alternative; boundary=f46d044288ca5f430a04f7380f13 Archived-At: http://mailarchive.ietf.org/arch/msg/hybi/foR7evm7OzUvWOjIVC2sOs-dULA Cc: "hybi@ietf.org" Subject: Re: [hybi] New Chrome WebSocket implementation: testers wanted X-BeenThere: hybi@ietf.org 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: Thu, 17 Apr 2014 07:34:23 -0000 --f46d044288ca5f430a04f7380f13 Content-Type: text/plain; charset=ISO-8859-1 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 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 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 >>> To: "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 >> >> > --f46d044288ca5f430a04f7380f13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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 nor= mal https request, whereas it doesn't when it has to do a wss interacti= on.
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, A= pr 17, 2014 at 5:41 AM, Adam Rice <ricea@google.com> wrote:
Dario,

T= hank 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&g= t; wrote:
Hi Adam,

We have tried the extended version of Chrome against our Lightstreamer Ser= ver and we have noticed that, with the new implementation enabled, the brow= ser can't open a WebSocket towards Lightstreamer Server in the followin= g 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 relat= ed not with the WebSocket protocol itself, but with the failure to establis= h 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 certi= ficate 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 i= mmediately closes the socket;
then the second attempt succeeds fu= lly.
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 <r= icea@google.com>
To: "hybi@ietf.org<= /a>" <hybi@ietf.= org>
Subject: [hybi] New Chrome WebSocket implementation: testers wanted
Message-ID:
=A0 =A0 =A0 =A0 <CAHixhFrA2FH6JOOFkd9sjBtgv= BKEO6CZ9K9T-NdKf8PvXTiG2A@mail.gmail.com>
Content-Type: text/plain; charset=3D"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, wherea= s the new
implementation does. You can examine the headers by opening the Network
panel in "Developer Tools" before creating the WebSocket connecti= on.

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

_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi



--f46d044288ca5f430a04f7380f13--