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

Kazuho Oku <kazuhooku@gmail.com> Thu, 20 October 2016 03:50 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27B47129689 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Oct 2016 20:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.932
X-Spam-Level:
X-Spam-Status: No, score=-6.932 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, 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 5PgL_h85fhd9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 19 Oct 2016 20:50:54 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED4C12946C for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 19 Oct 2016 20:50:53 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bx4JZ-0008FK-9n for ietf-http-wg-dist@listhub.w3.org; Thu, 20 Oct 2016 03:46:45 +0000
Resent-Date: Thu, 20 Oct 2016 03:46:45 +0000
Resent-Message-Id: <E1bx4JZ-0008FK-9n@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bx4JR-0008Cf-BX for ietf-http-wg@listhub.w3.org; Thu, 20 Oct 2016 03:46:37 +0000
Received: from mail-lf0-f43.google.com ([209.85.215.43]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <kazuhooku@gmail.com>) id 1bx4JM-0003mi-7E for ietf-http-wg@w3.org; Thu, 20 Oct 2016 03:46:34 +0000
Received: by mail-lf0-f43.google.com with SMTP id b81so60553039lfe.1 for <ietf-http-wg@w3.org>; Wed, 19 Oct 2016 20:46:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WKA32w5t0xtkXT1RGWupVvHt+iGkKBv7G0iIU7smuik=; b=GNQESDnAZLKMlwy9C2J1QaWpbQX4mc2H2+kB7JAHOZfw063i7IKaLq0Nzj6p4WfFjz BQcIrjVmTUhCZZHhYTs6tHwVZMdAalpqAT8vV5muoPyEsOgimRo6H4Yp4hxclWN/pFqL 35AUfqOMV6SLutq/LIftFKGunQ8N1jGzeHz9zouNzHq7dImpuls51vY6vJTUHUVVs+vK klMXBdcT8d799hGOulfFI+qG/fkNxjnhXTf+j/BAvP4LE7W318yTg6VlYcoPNsf9neqn fujjIYicCnbij0FmEWQj6Aw6uy9bG2Y4NMlGe33CmWX2zsFMcPqCY85anL1NQ6VQrWyn V5Ag==
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; bh=WKA32w5t0xtkXT1RGWupVvHt+iGkKBv7G0iIU7smuik=; b=JLSY5A3I5r4zo49TQYwHq5qN/9eHD4jjQRSImOI6hqXNl0jFowBhl8q8/vS+dCwKAD qFkM+aUW75bCwEMCZxa0owyjrYeC7EPo2Qi5mJknyIWh13M31enq1YIvJhs80+6j/d6z TbpeyBQuSqr2joRo8jYmkCaUk5Y762PNJX7+tZtt4k+miA5emXXuJ9dFsQtQiJ/BZZLh cNK/ohIznqlf0FnpbunjpruQFfKUx8LJPey4Ryff3k5lpie578MXuHSsaYX8CfArdcPf DNffeBxVZMEqTHnyev9O1uZeJiLfuqV5Ite9lFMVY+eqOr4D3yrxawslra8tRu5U6o0h FYyg==
X-Gm-Message-State: AA6/9Rlr28xtNOX4//GRTiVovg7Td1n/F25np3O1zDW/Ue8O0TcSq5vUtCWQojx3JoKi2Ybj0F/1ToQcbqNpuw==
X-Received: by 10.28.64.133 with SMTP id n127mr4573983wma.31.1476935164852; Wed, 19 Oct 2016 20:46:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Wed, 19 Oct 2016 20:46:04 -0700 (PDT)
In-Reply-To: <CA+3+x5E7OWPVbzgTo5XQcY5E1C9817ptpbj3PBmmxibctP_t5Q@mail.gmail.com>
References: <CAOdDvNrLJVxrPV54Jk3gKXmnZQQo8KGhaaCUu19phCLsP_H9zQ@mail.gmail.com> <CAG-EYCiJQQBe5_=vSn5sCC2inJgj+Pc6ePxgzw20AyzY1hAq7w@mail.gmail.com> <20161019165045.GA4278@LK-Perkele-V2.elisa-laajakaista.fi> <CANatvzzJ89JKteRrhO19c6gmw5xdbZMKMFwUPjQpQhjWM1VOvA@mail.gmail.com> <CA+3+x5E7OWPVbzgTo5XQcY5E1C9817ptpbj3PBmmxibctP_t5Q@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 20 Oct 2016 12:46:04 +0900
Message-ID: <CANatvzx0+6P8+SifWY=4uFJUZg5mTKsjEeQgn2=w+huPEa9kyQ@mail.gmail.com>
To: Tom Bergan <tombergan@chromium.org>
Cc: Ilari Liusvaara <ilariliusvaara@welho.com>, Van Catha <vans554@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset=UTF-8
Received-SPF: pass client-ip=209.85.215.43; envelope-from=kazuhooku@gmail.com; helo=mail-lf0-f43.google.com
X-W3C-Hub-Spam-Status: No, score=-3.5
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_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bx4JM-0003mi-7E 7a1bd57ff97cbf11c647a3b5a2a8f194
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)
Archived-At: <http://www.w3.org/mid/CANatvzx0+6P8+SifWY=4uFJUZg5mTKsjEeQgn2=w+huPEa9kyQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32648
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

2016-10-20 10:31 GMT+09:00 Tom Bergan <tombergan@chromium.org>rg>:
> On Wed, Oct 19, 2016 at 5:48 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
>>
>> Hi,
>>
>> 2016-10-20 1:50 GMT+09:00 Ilari Liusvaara <ilariliusvaara@welho.com>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.
>> >> https://datatracker.ietf.org/doc/draft-svirid-websocket2-over-http2/
>> >
>> > 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:
> http://www.grpc.io/docs/guides/concepts.html#bidirectional-streaming-rpc
> http://www.grpc.io/docs/guides/wire.html

Thank you for your comment.

I agree that a stream remains in open state until a frame with an
END_STREAM flag is sent by either of the two communication bodies. So
HTTP/2 as a spec. does not forbid using DATA frames for bidirectional
communication.

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

Yes.

This could be the case for any HTTP/2 gateway that translates incoming
requests to HTTP/1, that does not reject unknown schemes. And whether
such gateway needs to reject schemes that do not match to the
request-response model of HTTP seems to be vague in reading RFC 7540.
Section 8.1.2.3 states that:

      ":scheme" is not restricted to "http" and "https" schemed URIs.  A
      proxy or gateway can translate requests for non-HTTP schemes,
      enabling the use of HTTP to interact with non-HTTP services.

My interpretation of this paragraph would be that it is permitted for
an HTTP/2 intermediary to transmit requests with schemes other than
"http" or "https", expecting that an upstream server would process the
request according to the scheme, considering the fact that (per my
understanding) such action is permitted in HTTP/1.1.

-- 
Kazuho Oku