Re: 6455 Websockets and the relationship to HTTP

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC9C5127058 for <>; Fri, 2 Dec 2016 12:21:26 -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 og8Xp6JcUM7G for <>; Fri, 2 Dec 2016 12:21:25 -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 410841289B0 for <>; Fri, 2 Dec 2016 12:21:25 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cCuIN-0002pZ-4T for; Fri, 02 Dec 2016 20:18:59 +0000
Resent-Date: Fri, 02 Dec 2016 20:18:59 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cCuID-0002ni-6T for; Fri, 02 Dec 2016 20:18:49 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1cCuI6-0001PR-RG for; Fri, 02 Dec 2016 20:18:43 +0000
Received: by with SMTP id p66so110909559pga.2 for <>; Fri, 02 Dec 2016 12:18:14 -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=XlYSUBcgorDiCe9wHiqObenrgrTQRTRO+MOZLHGhBGU=; b=OIRg9CwzzgdgO5SlvRqvlXQLPTPY31e83/9HA5wOv20Pfd0sMkjQ7T8f7YRFSLSxHX ucIFteHXdxdgrgIrDykIr2sxWO3Dqhp7Z9DgoBjtf4FdhHHJB5E7A8jDCMLhyyEM51PS iTTB8Yu/wAvwbIMX7vmbaGk89zUujyS7gGV/zE6KJ8kKeVOXWpeqDKnQEjKkYXBHcd2E a6MxoR0/9vZByMcAcyZWW7j6BfWkpQS2OgYQvgG8C+TYTE54NJUVFMFHrWlYw4Ta+TXV 9gwQvv8vrzBTUuRzh6kdPMiFYETZVJAx4cglA8ZsBsMOHMrl9Y7t38dp8mfKKiTxZl3v QKhg==
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=XlYSUBcgorDiCe9wHiqObenrgrTQRTRO+MOZLHGhBGU=; b=Upz5rMs2CDMBtzrqFZ6tNMEouzC0QvIRlAA5bsjfAaT4iCkdjXp5pm3bBRYn8eQhTJ 53fnEvsKcNZfBAujFS2lkMS2HHa4LMaJ7OPAPkuUwS0xF39sV5ImqsKAtoBi2Y5j/JYm zDGBlXs5UkPeLdphOaBqH7kG650eP5sxx6osRGCHYpamRV+d+lTa8jHiFhfqZ4dM+t3I 4R9x7aVvlaT3hTSLiCmAyvBafokPifaUcqFQC93gFEPRZeLZn9b01424obWA9sMUJMj+ qd9rg2GWUb4Q8P6AomKccRaneP3w3IYrDBUAvqkGITtEQuiadw9JTbfN/UFG5+U385el 59gQ==
X-Gm-Message-State: AKaTC00pzmJM8KB/WHGpoh+6ku5uyeL39ZK8rVN+p0d6uuZWS3VU36lQdX3n/4QALQfqUQ==
X-Received: by with SMTP id g12mr98221121pla.62.1480709887857; Fri, 02 Dec 2016 12:18:07 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id s8sm9690696pfj.45.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 12:18:07 -0800 (PST)
To: Andy Green <>, Patrick McManus <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
Cc: HTTP Working Group <>
From: Jacob Champion <>
Message-ID: <>
Date: Fri, 02 Dec 2016 12:18:06 -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: 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1cCuI6-0001PR-RG ac4e9e8292e45ad5619e671b5ed9e1e3
Subject: Re: 6455 Websockets and the relationship to HTTP
Archived-At: <>
X-Mailing-List: <> archive/latest/33098
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 12/02/2016 11:54 AM, Andy Green wrote:
> On December 3, 2016 2:36:56 AM GMT+08:00, Jacob Champion <> wrote:
>> (Since frame boundaries don't have *semantic* meaning in WS, the major
>> thing to keep for WS/2 is the ability to send control frames in the
>> middle of a very large message, which IIUC the WS API does not
>> currently
> Nah... if it's sharing an h2 connection, he's just one muxed stream.  And ws specifies any intermediary may refragment ws frames anyway.  Individual ws1 frames have no guarantee of making it to the peer atomically.

Correct. That's what I meant by "frame boundaries don't have semantic 
meaning"; sorry if that was unclear.

> Of course ws (see RFC6455 5.4) explicitly "allows" "send[ing] control frames in the middle of a very large message"... a ws message comprises any number of frames of any legal length.  Inbetween the message fragment frames you may send control frames.

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.

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.

> So that one is just wrong I think.
>> allow. As for pings, the data reflected by the server could allow
>> clients to perform rudimentary latency monitoring or something else
>> clever at the application level, perhaps for clock synchronization...?)
> I never saw ws PING data like that

I have. So... there's that. :D In my particular case, it didn't make it 
into production (as far as I know), but I've *seen* it.