Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)

Tom Bergan <> Thu, 20 October 2016 01:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6942912984F for <>; Wed, 19 Oct 2016 18:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.931
X-Spam-Status: No, score=-6.931 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=-0.431, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qk6O1HLjDo3Z for <>; Wed, 19 Oct 2016 18:36:26 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFC54129495 for <>; Wed, 19 Oct 2016 18:36:26 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1bx2DI-0003Bp-9p for; Thu, 20 Oct 2016 01:32:08 +0000
Resent-Date: Thu, 20 Oct 2016 01:32:08 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bx2DA-0003B1-Nn for; Thu, 20 Oct 2016 01:32:00 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1bx2D4-0002wM-Et for; Thu, 20 Oct 2016 01:31:57 +0000
Received: by with SMTP id 139so132434193itm.1 for <>; Wed, 19 Oct 2016 18:31:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O3JenhQ/nfDAoKZ6W/Ss+1YyW1e+5xwsB25IjQ4he74=; b=PdzEzELnM/aQfyVSlOwPXCY64VqrwyclVazegd8LFclMHQ4WBHXdM3BdkCmIPTVf2j yHt3MwhSVO0x9bUgJUXx0GG8ymD2fSCarG4m9RVjrq1hc4eBNK9s+/BiaKXepJl9Qxht ujv1+6m4iacDRzB1oDmQggyE3RxiHQi8+dN7Y=
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=O3JenhQ/nfDAoKZ6W/Ss+1YyW1e+5xwsB25IjQ4he74=; b=RgC8pBpCB8IN0E63a7oyqbRNUKmmrr/BvB3SCZO7ulp8N7ohWHcDXoc7k3uPQWe/OQ 5dMrxHv1+YxnXDZb0LLwnwv3H58qYUui5z1V/9NGhwG7ZGJplFhnXSfdo0Ejy2pRu8ew nyOGIGlPMDx2vhITW1NtmfQ+ZHbdbjn4zq3vDQ+MlmbLrtTkpgx5MuVDd83r7tc3GKw6 2oInWeRj7Qc/ThGa1UbwmZfsOp2IWVAFjh77wZchtG/yu11d5tFERlx1CV4AVKaH+Z/G P/lOHyXAJ6jbzAqQmw8bfRqE9LuANHYeCPPF8goxV/kNbP3eMaXtyXx+MsssTjCkXqMy logQ==
X-Gm-Message-State: AA6/9RkKxyHYKbo0U1AeSjaYiFlr5/9kMjxDXSH/ewvf9uMem4e0oP7JsFW4+jROkrtCCi7P
X-Received: by with SMTP id y90mr9627440ioe.86.1476927088062; Wed, 19 Oct 2016 18:31:28 -0700 (PDT)
Received: from ( []) by with ESMTPSA id o144sm4415702itc.8.2016. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 19 Oct 2016 18:31:27 -0700 (PDT)
Received: by with SMTP id 66so57798976itl.1 for <>; Wed, 19 Oct 2016 18:31:27 -0700 (PDT)
X-Received: by with SMTP id a19mr5804277ita.4.1476927086957; Wed, 19 Oct 2016 18:31:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 19 Oct 2016 18:31:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Tom Bergan <>
Date: Wed, 19 Oct 2016 18:31:26 -0700
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Kazuho Oku <>
Cc: Ilari Liusvaara <>, Van Catha <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary=001a114534d260ed94053f41e2a3
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.2
X-W3C-Hub-Spam-Report: AWL=-1.010, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1bx2D4-0002wM-Et 487227b0df7b7baa433540487c7532ee
Subject: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)
Archived-At: <>
X-Mailing-List: <> archive/latest/32646
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Wed, Oct 19, 2016 at 5:48 PM, Kazuho Oku <> wrote:

> Hi,
> 2016-10-20 1:50 GMT+09:00 Ilari Liusvaara <>om>:
> > On Wed, Oct 19, 2016 at 10:03:18AM -0400, Van Catha wrote:
> >> I am particularly interest in the future of 2 way binary streaming.  So
> the
> >> topics of WebSocket, Streams API and other related. I have even put
> forward
> >> a draft related to the WebSocket part.
> >>
> >
> > Some quick review comments:
> >
> > - The handshake seems to negotiate compression and then the frames
> >   contain compression method indicator. Are there really multiple
> >   compression methods available on per-frame basis, or should the
> >   compression just be 1 bit (compressed or not)?
> > - The abbrevations in frame diagram are bit difficult to understand
> >   (have those be expanded in above text?).
> > - Somebody needs to try what this does against many HTTP/2 origins
> >   that don't support WebSockets2 and against intermediaries with
> >   custom server that actually supports it. Just to see what the
> >   heck happens (if it is nasty, one might need to use SETTINGS to
> >   signal support, either for WebSockets directly or for some sort
> >   of strict scheme).
> That's a good point.
> In case of H2O, all schemes are handling equally at the protocol
> layer. In other words, whatever the :scheme is, the server is designed
> to wait for a request, and then send response.
> My understanding is that the HTTP/2 specification is written in mind
> to allow such implementations, and that it would be a violation of
> HTTP/2 to introduce different interactions by using :scheme as an
> indicator. For example, transition of the stream states described in
> section 5.1 is not restricted to specific schemes.
> So if we are to start using the HTTP/2 framing layer to transmit
> websocket or other bi-directional communication, I think we should
> require negotiation using SETTINGS frame. Also, it might be beneficial
> to use a frame type other than DATA to convey bi-directional
> information to avoid potential issues (since the transition of the
> stream states are mostly related to how DATA frames are handled).

Ignoring the practical issues for a moment (which are obviously important),
which part of the H2 spec forbids bidirectional communication as desired by
WebSockets2? The stream state diagram in section 5.1 says that a stream
transitions from "idle" to "open" when the client/server sends/receives a
HEADERS frame (with CONTINUATIONs). A stream doesn't transition to a
"closed" state until a peer sends an ENDS_STREAM flag. Section 5.1 says: "A
stream in the 'open' state may be used by both peers to send frames of any
type." This seems to explicitly allow bidirectional communication with DATA
frames as desired by WebSockets2. Further, WebSockets2's bidirectional
communication looks very similar to bidirectional streaming in gRPC:

In practice, I could see that some servers will try to consume the entire
request before returning any kind of response, and this definitely might
interact poorly with WebSockets2.