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

Dario Crivelli <dario.crivelli@lightstreamer.com> Thu, 17 April 2014 07:34 UTC

Return-Path: <dario.crivelli@lightstreamer.com>
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 <hybi@ietfa.amsl.com>; 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 <hybi@ietfa.amsl.com>; 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 <hybi@ietf.org>; Thu, 17 Apr 2014 00:34:18 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id k14so75921wgh.10 for <hybi@ietf.org>; 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: <CAHixhFo3n_yc_kVqOoNOFqrDmrsAMDp4K7HVcztRuxu_4VBYqw@mail.gmail.com>
References: <CAPwYjp=uVdPLS4dq4xeuRXFN5di6x=ydv=agPPdBO82pMd6pDA@mail.gmail.com> <CAHixhFo3n_yc_kVqOoNOFqrDmrsAMDp4K7HVcztRuxu_4VBYqw@mail.gmail.com>
From: Dario Crivelli <dario.crivelli@lightstreamer.com>
Date: Thu, 17 Apr 2014 09:33:54 +0200
Message-ID: <CAPwYjpnd+B7f-Mk3RXTGLZFHXwvpMJPebDtWs_u1T+SXB7WPJA@mail.gmail.com>
To: Adam Rice <ricea@google.com>
Content-Type: multipart/alternative; boundary=f46d044288ca5f430a04f7380f13
Archived-At: http://mailarchive.ietf.org/arch/msg/hybi/foR7evm7OzUvWOjIVC2sOs-dULA
Cc: "hybi@ietf.org" <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 <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Apr 2014 07:34:23 -0000

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