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

Kazuho Oku <kazuhooku@gmail.com> Thu, 09 November 2017 02:41 UTC

Return-Path: <kazuhooku@gmail.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 7E310129AA8 for <hybi@ietfa.amsl.com>; Wed, 8 Nov 2017 18:41:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[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, 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 45Ta1uqmkEiK for <hybi@ietfa.amsl.com>; Wed, 8 Nov 2017 18:41:23 -0800 (PST)
Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 A0827126E64 for <hybi@ietf.org>; Wed, 8 Nov 2017 18:41:23 -0800 (PST)
Received: by mail-pg0-x229.google.com with SMTP id m18so3512990pgd.13 for <hybi@ietf.org>; Wed, 08 Nov 2017 18:41:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=j4mun2a5NcItUeyGV3ezeezAggvx0OuUqnUlYwriylc=; b=A9W+pRYetx3xJnHcHvMnN7Xk/C+ApIEcgEtn4VSM5KhSkc2w8jKEFCpYnzK217Takt 7wMl7syPzdRZqoFjq+lgRsNNSWxBpFDnWpflEq1pHpiXuBAY/lyNL4MOCY1ZbwGVb6PK W37XyuZ2qsGC8TsphCA8fgOAek6fh1K67njEKlcRA+kfMjMYFk7Iljt0+iX8F5hhkiMk ta0MJh8RScJhlUnhuhfZ20gdVDxjpJzMs4WuPESH0kXQ2dWS7gCLitZOmv0zlVMd/oXD /kkGN3/TE7yq5U8+SzyIhIaak/qWhg3qoyUe9ryPGUCqUn+Lg29QVWQpr6hvFpj2tuJb nJsg==
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=j4mun2a5NcItUeyGV3ezeezAggvx0OuUqnUlYwriylc=; b=D8vsWyN0/UO6EavlaTV+hbXRGEyGYQLgons5N5V7CzKAgg4en2pIQAwaT1pSmqCs5N M3oItukxCJfZD5/K/z5fHVhfS3sx5n/eMW8t7Vb9WA9cXqcp58dmUq8HT2u828lz1fCh JikJ03DY49Ktk8z1exZObVxatkiZwzpZkdWMioIA+Ep7m3jJxnW4xrO8chaLCQlJ5xnJ f7g6M7K+QrRN1ZRNq+Vtdzdu8Le8FYogAU7c2DJNOuH1PeKYo7UNkKEKG8KNxRAMqEdK S8IYmFfaDsEyJV0BGaNJviAXrD8k45COqqpnSEwFkLrJjE4+nIbBvmu6FgIjR9rQAhrR mpOA==
X-Gm-Message-State: AJaThX70m86PEyR7YraD4wMAQaO2VCmUXQ/mP+Ul/s67AUmVnALoKne6 avuWXATUN9iNOd77xGsZvtudwF35u1gRc79yGUFywfDx
X-Google-Smtp-Source: ABhQp+SOH/MRDcavP9VJf0ZJKkgLqHt5e+VnNv4TCtptxboSclVjG4P9zECodj0QAOtQudHNhepy6oxQlyhlcl4OUrc=
X-Received: by 10.84.198.35 with SMTP id o32mr2313239pld.214.1510195282989; Wed, 08 Nov 2017 18:41:22 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.187.131 with HTTP; Wed, 8 Nov 2017 18:41:22 -0800 (PST)
In-Reply-To: <CAOdDvNpWBw2Q36=XqkHwa4tc4wCrV6mumeah9w-ATkGJmUaZ9Q@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>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 9 Nov 2017 11:41:22 +0900
Message-ID: <CANatvzzdd6cr+Z=oLh=kU7PUTio2MGhdM2eppcUZkCjchNLHmQ@mail.gmail.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Cc: Andy Green <andy@warmcat.com>, John Fallows <john.fallows@kaazing.com>, hybi <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hybi/9GD84HCHpp0HszNGiOB6XQM2R04>
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 02:41:25 -0000

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:

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