Re: 6455 Websockets and the relationship to HTTP

Jacob Champion <> Fri, 02 December 2016 21:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F8EF12941A for <>; Fri, 2 Dec 2016 13:45:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.897
X-Spam-Status: No, score=-9.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PIARhd_qX7Tg for <>; Fri, 2 Dec 2016 13:45:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3FF3129418 for <>; Fri, 2 Dec 2016 13:45:29 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCvbU-0000YY-2v for; Fri, 02 Dec 2016 21:42:48 +0000
Resent-Date: Fri, 02 Dec 2016 21:42:48 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCvbL-0000Xj-Qx for; Fri, 02 Dec 2016 21:42:39 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cCvbA-0004um-Di for; Fri, 02 Dec 2016 21:42:29 +0000
Received: by with SMTP id p66so111568299pga.2 for <>; Fri, 02 Dec 2016 13:41:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=gZHScq+auseQA3HnyYPL6ks3ZI+8h6siHB4srs2Z0xY=; b=nad2f9+bLsGm1AoD3b0BpKSICv9QhZ14ikAuT5z2pEC9+Rmid6hYhDrnPJM/9yqehU fZPYLdQL1CIAtZDOXTQqtgoEm6glEI758v6xStbpM8/4+YLlE7kkG3uEYgd7dVLW4gbx o0MV5i/IdtzoEdhj/eQrYKNkUqpk73hf8mG4mie2fVcUxzNWRATgG3twLEHA3ZV9c1Ug diNIgs9Lb3kKaW6w6VFKdZcGgnRFpTKwu68n4vMbPoPe9XBHHM46QvfnWLei1wUlrv7g iyGgFfguDvJ2ONkle0S6W3djFoAuIOJ63WZ78CV+BCR7Uchj3zAjVycpN+lV7EMe27cO nJSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=gZHScq+auseQA3HnyYPL6ks3ZI+8h6siHB4srs2Z0xY=; b=QZWqx6DaLAwnsl98snP0cSzJpHZ9UVxj4PJCzVmJplvp17fL1RwEppb6m6TL4f573+ MJWvg2CVvPJbGawkH+gl1l3TTpLe9guKGxY++Qsvrib8jSXZDWq5zXUxQh5MWu781bcs oeVMSw+borhRiKcauXohG+jUHI9/AbI6/FVpdxb3EUcgVzIupYpmVB8168e3mTdgtHqz nLOGXF86v8rooZEioYFo/zE/A68UuJl/0VupVQ8PBENcEJdBuDBGxy6315y9LqV7RW4O INRemeI5iZ9WGlvZtpTZp+2P8W4J9wlAm8ZRr3s80LB/07ubzrqxYgXIkNM4Z8AeI9D1 /U7g==
X-Gm-Message-State: AKaTC02RMV2CYo99aiZIHHUKzXdFGU5KoeEWSDugk8Kc8Jrc4J8CN5yjBsYDpxBp8lIczQ==
X-Received: by with SMTP id 1mr100131175plu.133.1480714908319; Fri, 02 Dec 2016 13:41:48 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id c71sm9909466pga.22.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 13:41:47 -0800 (PST)
To: Andy Green <>, Patrick McManus <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Cc: HTTP Working Group <>
From: Jacob Champion <>
Message-ID: <>
Date: Fri, 02 Dec 2016 13:41:46 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.0
X-W3C-Hub-Spam-Report: AWL=-0.010, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cCvbA-0004um-Di 4c2c58366dcaa5d78f0e2595ad31b438
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33100
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 12/02/2016 12:58 PM, Andy Green wrote:
> On December 3, 2016 4:18:06 AM GMT+08:00, Jacob Champion <> wrote:
>> My point is just that this ability to multiplex control frames inside
>> of
>> in-flight messages is not something that is explicitly exposed by the
>> JS
>> API, but it may be something that a (non-browser) client requires for
>> proper operation. I think WS/2 should still support it, regardless of
>> whether or not a JS client can make use of it.
> OK.  Although the only relevant control frames are PING / PONG.

CLOSE too, plus any control frames added to the protocol between now and 
the release of WS/2.

> And if a client wants to send control frames inside a huge message, that client must have explicitly fragmented the message already.
> The general idea is just map ws2 payload frames direct to h2 framing... refragmenting them to fit.  In that way, 'supporting' ws1 63-bit frame lengths compatibly doesn't require 63-bit frame lengths in ws2 because ws always allows refragmentation of frames.


> So it only creates more fragmentation / opportunities to insert control frames, so no problem.
>> Let me step back: when you say that your goal is to "provide a
>> transport
>> for JS WS API on h2", my fear is that this could lead to a situation
>> where semantics that are part of WS/1 are removed from WS/2 for no
>> reason other than "Javascript clients don't need it, so no one else
>> does
>> either." I would like to avoid that.
> What I meant by that is ws1 wire protocol can go out the window completely.  The job is not wrap ws1 verbatim in h2 frames, keep ws1 negotiation headers, masking, etc.  It can be radically recast to align with h2 while following the JS API, and fully exploit new possibilities like roundtrip elimination.
> I agree it should make some effort to not break non JS / browser uses.  But it's no coincidence there are only a tiny number of corner cases about that -- ws1 was itself designed to implement a transport for the ws JS API.

It sounds like we're on the same page, as long as the eventual 
solution's authors understand those corner cases, and that the 
functionality provided by WebSocket is (to a minor extent) a superset of 
what's provided by the JS API. In particular, I agree that we don't 
necessarily need to be bound by the current wire format, or the same 
HTTP-buster security features, as WS/1.