Re: 6455 Websockets and the relationship to HTTP

Van Catha <> Mon, 05 December 2016 01:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 729EC129667 for <>; Sun, 4 Dec 2016 17:03:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.396
X-Spam-Status: No, score=-9.396 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.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 KWaMHHPc1OHA for <>; Sun, 4 Dec 2016 17:03:28 -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 6B99B12965D for <>; Sun, 4 Dec 2016 17:03:27 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cDhdW-0007OY-Rt for; Mon, 05 Dec 2016 01:00:06 +0000
Resent-Date: Mon, 05 Dec 2016 01:00:06 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cDhdJ-0005QZ-FQ for; Mon, 05 Dec 2016 00:59:53 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cDhd9-0002Fc-94 for; Mon, 05 Dec 2016 00:59:48 +0000
Received: by with SMTP id w33so300230277qtc.3 for <>; Sun, 04 Dec 2016 16:59:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/z4FGirBdl07Vl3McHmWc4+ErAxwX7HtV1aGmjAnMYo=; b=DPhOBELeVMUAVTRzVxI0FU5zwKuFdqxHm+QpTah5hXhV8GRSKTTldwK0ptob55ww88 3fh4Nn6JMIqy6N3u6jERzL+16VliNC4VYjsSichnxNwFRCJqP5OX6SDMIUx4VvFFa9lc i0XHNfyX+SE4ygzQBkn0PhxuqTQaVks8x1ynUWxSKB0tHfCAcvVu4As0ZTkU1lrSZOj7 tgCJndcJc8LeiLiZI5/iXK6CxHI6cni1W3+uOSkhtW4EqYkii1VnnJgjQC2cC+B3203A wW+nm+atpRZqlQoB3yp/xrd+heqsN+kac4zAG60esTgmF40b5ogbZACLa5rDwVuEbJXR M4tA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/z4FGirBdl07Vl3McHmWc4+ErAxwX7HtV1aGmjAnMYo=; b=JT0oanzHbTfN8Zslfaniwl5H0vpnmiopwcLsTqH4tOXggIrb/TuQN0SHTgn+zXEH3s V0pViFV/CDOtr9S+42yyx8uC5Vor6Qlb3IPNi5UnYPFjwea0SaRoGRfzbXsY+E1h2Nve CxCsYYyhq9OgWsAR3OQCapoDzQ/64m+PqvYddJWZHNt67kgj7pI0gNFOeYg4Qbuo6SMo +pmEuDOBezi4e5Nak4K5P1oJtkUnMmrL6FkDYrRsxUU9zaAa9+AZHUaACk9gxzN5joZs yZz1gWIBPSBd1cz5neN3dYC0500j+r+2UHLobhiKbueZzIMRQdhQBUa8/wuw/xvbsdhv VTlQ==
X-Gm-Message-State: AKaTC02qkPxZhOW0Xg1l20XsA/A6r+oLH9/tyQC4xMRasY5TFmVYqBEwa8tIWEaB1IvMmbqYeA4phNz4+dH+EA==
X-Received: by with SMTP id u40mr48361572qtc.110.1480899551748; Sun, 04 Dec 2016 16:59:11 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sun, 4 Dec 2016 16:59:11 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Van Catha <>
Date: Sun, 04 Dec 2016 19:59:11 -0500
Message-ID: <>
To: Jacob Champion <>
Cc: Andy Green <>, Patrick McManus <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a11407360bb07e60542decb3d"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Scan-Sig: 1cDhd9-0002Fc-94 2c42da17f61b3824718f6d7aeccafaf6
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33105
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

I do not see the need for Ping, Pong or Close ws frames. The h2/quic
transport layer handles this. If you want to measure latency then send your
own pings/pongs, do not bake it into the protocol.  There is no need for
this, and if there is, please present a compelling reason.

The clientside API should not change, but it should definitely be extended
OR more functionality should be added to browsers, like the ability to
compress data from inside JS land.

On Fri, Dec 2, 2016 at 4:41 PM, Jacob Champion <> wrote:

> 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.
> Agreed.
> 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.
> --Jacob