Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

Wenbo Zhu <wenboz@google.com> Thu, 09 November 2017 21:42 UTC

Return-Path: <wenboz@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA8FE127005 for <hybi@ietfa.amsl.com>; Thu, 9 Nov 2017 13:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 Ke_7cjKTlf8u for <hybi@ietfa.amsl.com>; Thu, 9 Nov 2017 13:42:10 -0800 (PST)
Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E29E124D37 for <hybi@ietf.org>; Thu, 9 Nov 2017 13:42:10 -0800 (PST)
Received: by mail-wm0-x234.google.com with SMTP id y80so19974282wmd.0 for <hybi@ietf.org>; Thu, 09 Nov 2017 13:42:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O9WpxIYGgwC4BqOeTykHrcNRmLohhtM8/pYDPYdw9wc=; b=CLza3m1A9CGrL66M7xfAhOie1FrPwt7P0jG9X9oTERu9vYCjwMW7X3iXXdVbhGGZqn WX943sQa+Mpkd13OkxheqgkrvbHzgG9TEnPJdraZrDgBxhOm0NPQGLPxDYmgoyw1Vte0 RD5bzKBmfAIhYlFpz6AFiAUI5/9ibHmBzC8JhqoUs1ZldVitv8BWyFyOYGtSfHVAZANE sBuz9bW08lDtdV72H9MMZ3L5wNOxk9MJsyAxCVTLIAULK7J3qgjOwSbb/nIvy7W0mEIW QLO6re5LcVDIEVl7A1G+TMTYM4V4aJ/+voJnKakTsyBzWZypWFSoPSjg1LLA0GdeHYmU QqQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O9WpxIYGgwC4BqOeTykHrcNRmLohhtM8/pYDPYdw9wc=; b=Ya8jyPosBbowp3czzE9290MfLPQl7sjqX7HBLW9axBWvefnnICkHUeD6qjoY1ZMEb4 h+WqAZgl5tbx7edYfjR2SvKvvaj0vz9L2E+jpetmN8fbGbZgQf1UVEYpc9hCLx2ZlGs0 rZFMnumk4UO2bzLtet7fy1wswB2fV7nNEQQHdfm0uxcG9HwSbSlOmZCTnf1TJBFHlhN0 yakt3FSsteECI0qqX2zGI6Cge/+zwH8Nymx+iK//zRV/Lnz7YghKd5nl7BclDhWwgA7e QCorNUpjldzURomoXjCYDNnrNaqqDOd4i43spFz1vFdp4ObKlQrQhBGRUlOkTWMK/at1 jgIA==
X-Gm-Message-State: AJaThX5KzpyACKSuuKTgWLpw7yL6dZ/YaMxR69szuOy4+MUl0Z600rud Cu3Akrb3SUnFrwhsF0oBzTkfi41vxeKTBu0g7EwohHhjkr4=
X-Google-Smtp-Source: AGs4zMZFsDlJKE5U3J25ajdhEbz0XsH35Uss2+0pHGMxpWkobry/WKbjnU1D1e6GFnGaepjtv8NvLgSU1Ggj1nYCYGY=
X-Received: by 10.28.107.5 with SMTP id g5mr873750wmc.125.1510263728089; Thu, 09 Nov 2017 13:42:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.184.195 with HTTP; Thu, 9 Nov 2017 13:42:06 -0800 (PST)
In-Reply-To: <CANatvzzdd6cr+Z=oLh=kU7PUTio2MGhdM2eppcUZkCjchNLHmQ@mail.gmail.com>
References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> <CAOdDvNrC1PgribOiDc93hfCDFSJbjodnU8=yeNWgzkq4Cm-2Cg@mail.gmail.com> <CACAJL3nEB5jGFXpqPZ2ErdkezCHpZE1CnqXy0yomBP-v7jcGRA@mail.gmail.com> <bf6aabaf-227b-fc3d-8142-57712a2e8935@warmcat.com> <CAOdDvNp1dKV8-t_r8KFMkJdRgUh_5VtNJ3unORgEpg5EeOAGZg@mail.gmail.com> <CAOdDvNpWBw2Q36=XqkHwa4tc4wCrV6mumeah9w-ATkGJmUaZ9Q@mail.gmail.com> <CANatvzzdd6cr+Z=oLh=kU7PUTio2MGhdM2eppcUZkCjchNLHmQ@mail.gmail.com>
From: Wenbo Zhu <wenboz@google.com>
Date: Thu, 9 Nov 2017 13:42:06 -0800
Message-ID: <CAD3-0rPPGx4k+ksk-QDnNhnescfPHiYSJ-z2AQeMR2=khaO_HQ@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a11462f560872a7055d93adef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/DtVxKLaUXdREFT_t-pUl090cOpQ>
Subject: Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hybi/>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Nov 2017 21:42:13 -0000

I think this is a great proposal, defining a generic tunneling mechanism
and treating websocket as a special case, with handshake/payload a concern
for Web APIs and frameworks.

Two more notes:
1. as I understand, RFC7540 only states that early 2xx responses are
allowed, i.e. when response headers are generated, any pending request body
becomes insignificant. Therefore the explicit tunneling mechanism is
necessary to signal to proxies/frameworks that a full-duplex byte-stream is
being tunneled as a http/2 stream.
2. with such a generic tunneling mechanism, any TCP based L7 protocol can
be multiplexed over http2, and the explicit handshake (semantically an
inbound RPC)  allows metadata to be exchanged as http/2 headers v.s. using
transport (TCP) headers.


On Wed, Nov 8, 2017 at 6:41 PM, Kazuho Oku <kazuhooku@gmail.com>; wrote:

> Hi Patrick,
>
> 2017-11-02 20:27 GMT+09:00 Patrick McManus <pmcmanus@mozilla.com>;:
> > Here are my plans for -02
> >
> > * websockets parameters (sub-protocol, etc..) into h2 HEADERS
> >
> > * define the websockets target URI scheme for CONNECT as being http/https
> > when using 6455. I actually think this is a change from 6455 but I can
> live
> > with it if its defined. Mostly the concern is around legacy pac.
> >
> > * stick with CONNECT as the method for the moment.. my thinking here is
> that
> > CONNECT is already a strange beast with special code doing almost what we
> > want here anyhow.. replicating that is not great. I would rather have a
> > pseudo header be the version specific thing (which is expected of pseudo
> > headers) than adding a new method which is typically not.
>
> This might be unnecessary, but I wonder if it's worth adjusting the
> approach so that it could be converted into a generic way of upgrading
> an HTTP/2 stream into a bidirectional channel.
>
> To me it seems that we are removing almost all features specific to
> WebSocket. The only things remain specific are:
>
> * use of `CONNECT` as the method; having one method would be fine for
> websocket (since it only allows the use of `GET`), but that is not
> case for other upgrades (e.g. HTTP/2)
> * not using 101 as a way to notify protocol change
> * no way to specify which non-end-to-end header is required for
> upgrade (e.g. HTTP2-Settings)
>
> If we adjust the three issues (for example, by allowing any method to
> be specified, and use the existence of :upgrade: pseudo header as a
> signal; use 101 to signal protocol change; use attributes of :upgrade:
> header to specify additional headers required for the upgrade), I
> think the approach would become generic.
>
> For example, creating a websocket tunnel through HTTP/2 would look like
> below.
>
> Request:
>   :method: GET
>   :scheme: https
>   :authority: server.example.com
>   :path: /chat
>   :upgrade: websocket
>   sec-websocket-key: dGhlIHNhbXBsZSBub25jZQ==
>   origin: http://example.com
>   sec-websocket-protocol: chat, superchat
>   sec-websocket-version: 13
>   <data is same as RFC6455>
>
> Response:
>   :status: 101
>   :upgrade: websocket
>   sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
>   sec-websocket-protocol: chat
>   <data is same as RFC6455>
>
> Or in case of upgrading an HTTP/2 stream to HTTP/2 connection:
>
"HTTP/2 sub-connection"  ?


>
> Request:
>   :method: GET
>   :scheme: http
>   :authority: server.example.com
>   :path: /
>   :upgrade: h2c; http2-settings
>   http2-settings: <base64url encoding of HTTP/2 SETTINGS payload>
>   <may contain request body>
>
> Response:
>   :status: 101
>   :upgrade: h2c
>   <data is same as RFC7540>
>
> In this example, the :upgrade: pseudo header is used to convey the
> connection headers required for upgrade (as the following elements of
> the header field value), so that a reverse proxy receiving the request
> could convert it to an HTTP/1 request with a "Connection: upgrade,
> http2-settings" header.
>
> The approach might be overly generic than what we need. OTOH, having a
> generic mechanism help us, because we would no longer need to have any
> protocol-specific code in a reverse proxy. Hence asking about the
> possibility.
>
> --
> Kazuho Oku
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>