From nobody Thu Nov 2 04:27:12 2017 Return-Path: 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 3A4C013F6F9 for ; Thu, 2 Nov 2017 04:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.666 X-Spam-Level: X-Spam-Status: No, score=0.666 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 eZgwLYiMyDNl for ; Thu, 2 Nov 2017 04:27:08 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 53C0313F6C9 for ; Thu, 2 Nov 2017 04:27:08 -0700 (PDT) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) by linode64.ducksong.com (Postfix) with ESMTPSA id 7FC403AB8A for ; Thu, 2 Nov 2017 07:27:06 -0400 (EDT) Received: by mail-lf0-f46.google.com with SMTP id 90so6031465lfs.13 for ; Thu, 02 Nov 2017 04:27:06 -0700 (PDT) X-Gm-Message-State: AMCzsaU0pwHKMFltZhBelIASBGOh2q8hWNWgtLMWD1YFnKGfq5JI0dzH A1uqlDRknWQNZqpArci3ASlzunvQ+2DODFybkyA= X-Google-Smtp-Source: ABhQp+SQoZVFbkpCesALQzCp9tTid38Amuy/6ygUh8/noOERn15YoBcTpsp9qKBNoNTVxmAIirefqplNehh7U2sJJsk= X-Received: by 10.25.21.233 with SMTP id 102mr1105757lfv.252.1509622025258; Thu, 02 Nov 2017 04:27:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Thu, 2 Nov 2017 04:27:04 -0700 (PDT) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Patrick McManus Date: Thu, 2 Nov 2017 12:27:04 +0100 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus Cc: Andy Green , John Fallows , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="001a114081268f8db8055cfe4426" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Nov 2017 11:27:10 -0000 --001a114081268f8db8055cfe4426 Content-Type: text/plain; charset="UTF-8" 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. --001a114081268f8db8055cfe4426 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here are my plans for -02

* = websockets parameters (sub-protocol, etc..) into h2 HEADERS
<= br>
* define the websockets target URI scheme for CONNECT as bein= g http/https when using 6455. I actually think this is a change from 6455 b= ut I can live with it if its defined. Mostly the concern is around legacy p= ac.

* 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 no= t 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 typ= ically not.

--001a114081268f8db8055cfe4426-- From nobody Thu Nov 2 22:55:13 2017 Return-Path: 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 3489C13FBDF for ; Thu, 2 Nov 2017 22:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GN2yfGbK_vwH for ; Thu, 2 Nov 2017 22:55:09 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3D28613FBB0 for ; Thu, 2 Nov 2017 22:55:08 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id vA35t3oC015976; Fri, 3 Nov 2017 06:55:03 +0100 Date: Fri, 3 Nov 2017 06:55:03 +0100 From: Willy Tarreau To: Patrick McManus Cc: Andy Green , John Fallows , hybi , HTTP Working Group Message-ID: <20171103055503.GC15878@1wt.eu> References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 05:55:11 -0000 On Thu, Nov 02, 2017 at 12:27:04PM +0100, Patrick McManus wrote: > 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. +1 on all this! Willy From nobody Wed Nov 8 18:41:28 2017 Return-Path: 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 ; 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 ; 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 ; Wed, 8 Nov 2017 18:41:23 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id m18so3512990pgd.13 for ; 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: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Kazuho Oku Date: Thu, 9 Nov 2017 11:41:22 +0900 Message-ID: To: Patrick McManus Cc: Andy Green , John Fallows , hybi , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 : > 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 Response: :status: 101 :upgrade: websocket sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= sec-websocket-protocol: chat 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: Response: :status: 101 :upgrade: h2c 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 From nobody Thu Nov 9 13:42:13 2017 Return-Path: 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 ; 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 ; 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 ; Thu, 9 Nov 2017 13:42:10 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id y80so19974282wmd.0 for ; 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: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Wenbo Zhu Date: Thu, 9 Nov 2017 13:42:06 -0800 Message-ID: To: Kazuho Oku Cc: Patrick McManus , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="001a11462f560872a7055d93adef" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Nov 2017 21:42:13 -0000 --001a11462f560872a7055d93adef Content-Type: text/plain; charset="UTF-8" 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 wrote: > Hi Patrick, > > 2017-11-02 20:27 GMT+09:00 Patrick McManus : > > 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 > > > Response: > :status: 101 > :upgrade: websocket > sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= > sec-websocket-protocol: chat > > > 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: > > > Response: > :status: 101 > :upgrade: h2c > > > 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 > --001a11462f560872a7055d93adef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is a great proposal, defining a generic tunne= ling mechanism and treating websocket as a special case, with handshake/pay= load a concern for Web APIs and frameworks.

Two more not= es:=C2=A0
1. as I understand, RFC7540 only states that early 2xx = responses are allowed, i.e. when response headers are generated, any pendin= g request body becomes insignificant. Therefore the explicit tunneling mech= anism 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 gener= ic tunneling mechanism, any TCP based L7 protocol can be multiplexed over h= ttp2, and the explicit handshake (semantically an inbound RPC)=C2=A0 allows= metadata to be exchanged as http/2 headers v.s. using transport (TCP) head= ers.


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/ht= tps
> 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 i= s 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 pseu= do
> headers) than adding a new method which is typically not.

This might be unnecessary, but I wonder if it's worth adjus= ting 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 bel= ow.

Request:
=C2=A0 :method: GET
=C2=A0 :scheme: https
=C2=A0 :authority: server.example.com
=C2=A0 :path: /chat
=C2=A0 :upgrade: websocket
=C2=A0 sec-websocket-key: dGhlIHNhbXBsZSBub25jZQ=3D=3D
=C2=A0 origin: http://example.com
=C2=A0 sec-websocket-protocol: chat, superchat
=C2=A0 sec-websocket-version: 13
=C2=A0 <data is same as RFC6455>

Response:
=C2=A0 :status: 101
=C2=A0 :upgrade: websocket
=C2=A0 sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=3D
=C2=A0 sec-websocket-protocol: chat
=C2=A0 <data is same as RFC6455>

Or in case of upgrading an HTTP/2 stream to HTTP/2 connection:
"HTTP/2 sub-connection"=C2=A0 ?
=C2=A0

Request:
=C2=A0 :method: GET
=C2=A0 :scheme: http
=C2=A0 :authority: server.example.com
=C2=A0 :path: /
=C2=A0 :upgrade: h2c; http2-settings
=C2=A0 http2-settings: <base64url encoding of HTTP/2 SETTINGS payload>= ;
=C2=A0 <may contain request body>

Response:
=C2=A0 :status: 101
=C2=A0 :upgrade: h2c
=C2=A0 <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

--001a11462f560872a7055d93adef-- From nobody Thu Nov 9 21:50:08 2017 Return-Path: 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 B62D912EAF9 for ; Thu, 9 Nov 2017 21:50:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no 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 fHeIqswq-rqh for ; Thu, 9 Nov 2017 21:50:04 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E87112EAB6 for ; Thu, 9 Nov 2017 21:50:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D237B5DE4C; Fri, 10 Nov 2017 07:50:01 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id seicjA-C1-UB; Fri, 10 Nov 2017 07:49:59 +0200 (EET) Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPS id D6E1E2315; Fri, 10 Nov 2017 07:49:51 +0200 (EET) In-Reply-To: References: To: Wenbo Zhu , Kazuho Oku Date: Fri, 10 Nov 2017 07:49:57 +0200 (EET) Sender: hurtta@hurtta09lk.keh.iki.fi From: Kari Hurtta CC: Patrick McManus , hybi , HTTP Working Group , Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha46+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171110055001.D237B5DE4C@welho-filter3.welho.com> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 05:50:07 -0000 > 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. Yes, full-duplex byte-stream is quote different from http request-response model. 8.1. HTTP Request/Response Exchange https://tools.ietf.org/html/rfc7540#section-8.1 states ------------- An HTTP request/response exchange fully consumes a single stream. A request starts with the HEADERS frame that puts the stream into an "open" state. The request ends with a frame bearing END_STREAM, which causes the stream to become "half-closed (local)" for the client and "half-closed (remote)" for the server. A response starts with a HEADERS frame and ends with a frame bearing END_STREAM, which places the stream in the "closed" state. An HTTP response is complete after the server sends -- or the client receives -- a frame with the END_STREAM flag set (including any CONTINUATION frames needed to complete a header block). A server can send a complete response prior to the client sending an entire request if the response does not depend on any portion of the request that has not been sent and received. When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i.e., a frame with the END_STREAM flag). Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons. -------------- / Kari Hurtta From nobody Thu Nov 9 22:15:03 2017 Return-Path: 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 C07E612EB0D for ; Thu, 9 Nov 2017 22:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 5yg8PU0DCBqE for ; Thu, 9 Nov 2017 22:14:58 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DA0012EB37 for ; Thu, 9 Nov 2017 22:14:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 1349EB532F; Fri, 10 Nov 2017 08:14:56 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id uuk4hQwEl5NC; Fri, 10 Nov 2017 08:14:55 +0200 (EET) Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPS id 3A1312313; Fri, 10 Nov 2017 08:14:48 +0200 (EET) In-Reply-To: References: To: Wenbo Zhu , Kazuho Oku Date: Fri, 10 Nov 2017 08:14:53 +0200 (EET) Sender: hurtta@hurtta09lk.keh.iki.fi From: Kari Hurtta CC: Patrick McManus , hybi , HTTP Working Group , Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha46+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171110061456.1349EB532F@welho-filter2.welho.com> Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 06:15:02 -0000 > 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. >> Request: >> :method: GET >> :scheme: https >> :authority: server.example.com >> :path: /chat >> :upgrade: websocket 8.1.2.1. Pseudo-Header Fields https://tools.ietf.org/html/rfc7540#section-8.1.2.1 states -------- Pseudo-header fields are only valid in the context in which they are defined. Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests. Pseudo-header fields MUST NOT appear in trailers. Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (Section 8.1.2.6). -------- Then that ":upgrade" works as explicit tunneling mechanism, IF you can trust that response is treated as mailformed (stream error of type PROTOCOL_ERROR) when proxies/frameworks does not subscribe that tunneling mechanism. Can you trust that? / Kari Hurtta From nobody Thu Nov 9 22:51:25 2017 Return-Path: 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 391DA12762F for ; Thu, 9 Nov 2017 22:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 AIcIZE-A8c26 for ; Thu, 9 Nov 2017 22:51:22 -0800 (PST) Received: from mail.warmcat.com (mail.warmcat.com [163.172.24.82]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DDF51242EA for ; Thu, 9 Nov 2017 22:51:22 -0800 (PST) To: Kari Hurtta , Wenbo Zhu , Kazuho Oku Cc: Patrick McManus , hybi , HTTP Working Group References: <20171110061456.1349EB532F@welho-filter2.welho.com> From: Andy Green Message-ID: <539a34dd-5d56-15a6-df81-50a48b4c18f7@warmcat.com> Date: Fri, 10 Nov 2017 14:50:32 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 In-Reply-To: <20171110061456.1349EB532F@welho-filter2.welho.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 06:51:24 -0000 On 11/10/2017 02:14 PM, Kari Hurtta wrote: >> 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. > >>> Request: >>> :method: GET >>> :scheme: https >>> :authority: server.example.com >>> :path: /chat >>> :upgrade: websocket > > 8.1.2.1. Pseudo-Header Fields > https://tools.ietf.org/html/rfc7540#section-8.1.2.1 > > states > > -------- > > Pseudo-header fields are only valid in the context in which they are > defined. Pseudo-header fields defined for requests MUST NOT appear > in responses; pseudo-header fields defined for responses MUST NOT > appear in requests. Pseudo-header fields MUST NOT appear in > trailers. Endpoints MUST treat a request or response that contains > undefined or invalid pseudo-header fields as malformed > (Section 8.1.2.6). > > -------- > > Then that ":upgrade" works as explicit tunneling mechanism, IF you can trust > that response is treated as mailformed (stream error of type PROTOCOL_ERROR) > when proxies/frameworks does not subscribe that tunneling mechanism. > > Can you trust that? How about putting a gratuitous content-length: 0 in one side's headers or both? If somebody doesn't really understand what the endpoints are up to and continues along normal h2 lines, they should fail the stream on the first DATA turning up then. -Andy > / Kari Hurtta > > From nobody Thu Nov 9 23:05:43 2017 Return-Path: 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 5048F12EB95 for ; Thu, 9 Nov 2017 23:05:41 -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 OAaCeHMdIBY4 for ; Thu, 9 Nov 2017 23:05:39 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::230]) (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 C865312EB88 for ; Thu, 9 Nov 2017 23:05:21 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id o7so6760636pgc.4 for ; Thu, 09 Nov 2017 23:05:21 -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=Jrva0bW8E/CQ8wKAdhaV07nJiaNuhnAODN56BPPNr1c=; b=gNvx1EjBkWBBcfpWJ8asoQ/YwXBr5Uhrc6zzjbb8OIn7sdUVROIZchhT1qShvRGaI9 VeHal3OkVNNsqXtYK30HALpqWLzT7w6rFh2FeJos/PzvDC/a0ntgL+6vvM/IbmNVbzbg 2GlNnU41rvfxY6wATdCKPA8Lv06rT2dO7Bd0L3GdNfj7R4A1J/x6BU1xN/eKFEDzBK/b aTI0/3eHIKhTEaaed4vEhKXuus/gcUs68kK4Z/uffNx4mJoCI53ljE/LkKm2x0hiB3zH MSth9qEKXlC0bebPk9NYgOL8i3gFLsKcRh/qycn6MQ/RhuF2Vf/UQnyR2YOm8pUzet/g 3yUA== 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=Jrva0bW8E/CQ8wKAdhaV07nJiaNuhnAODN56BPPNr1c=; b=TRPylq6ekI0cyv9QcGM5xskeI19RvnDwTeonk4tK13DerrrYqWJwFjnAY9n0LoJaS5 OIHO6q4AS4lyzCImgVoEwMNi2w84xW0h+6voUs1BYAw3jllxsUlVzU97EcYFWh4s9C8C OZoeWUZcLTp4air2+PJDkGMUlYC4g0Xg7rGino63El3ihjMSgq6704aby3MFZ1CtYc+P Ht/hWTxK4WiSBEYPbWnppBngRvtvM7Xf1gVW/S8Wa4Nk4j1XL3GL7DbxfDphc+vFWuFC 3iZEQrjrMlpjoxP0ZtL6TC+OaZidn4LLh8kl0FwnsmfqLVhXFfJpYgIyZuXr4bvu/qbJ d58Q== X-Gm-Message-State: AJaThX6L7ctPa2HyxvUrohgypXN9bSYAf3xzNg+hNk7ZUPEU+MXNDlnP kqhLNAJPE0ZKnoT7HCL7QaXzub8uD7cmLvQj8lI= X-Google-Smtp-Source: ABhQp+QSzKWirxkll+7uUUJuql2AqNKWeioXzHXDYTiUFLZaLJdW4udka7gjQkEqDGUwgo28prug8T99CzVfWt7zy1U= X-Received: by 10.84.129.36 with SMTP id 33mr3216902plb.303.1510297521322; Thu, 09 Nov 2017 23:05:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.159.9 with HTTP; Thu, 9 Nov 2017 23:05:20 -0800 (PST) In-Reply-To: <20171110061456.1349EB532F@welho-filter2.welho.com> References: <20171110061456.1349EB532F@welho-filter2.welho.com> From: Kazuho Oku Date: Fri, 10 Nov 2017 16:05:20 +0900 Message-ID: To: Kari Hurtta Cc: Wenbo Zhu , Patrick McManus , hybi , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 07:05:41 -0000 2017-11-10 15:14 GMT+09:00 Kari Hurtta : >> 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. > >>> Request: >>> :method: GET >>> :scheme: https >>> :authority: server.example.com >>> :path: /chat >>> :upgrade: websocket > > 8.1.2.1. Pseudo-Header Fields > https://tools.ietf.org/html/rfc7540#section-8.1.2.1 > > states > > -------- > > Pseudo-header fields are only valid in the context in which they are > defined. Pseudo-header fields defined for requests MUST NOT appear > in responses; pseudo-header fields defined for responses MUST NOT > appear in requests. Pseudo-header fields MUST NOT appear in > trailers. Endpoints MUST treat a request or response that contains > undefined or invalid pseudo-header fields as malformed > (Section 8.1.2.6). > > -------- > > Then that ":upgrade" works as explicit tunneling mechanism, IF you can trust > that response is treated as mailformed (stream error of type PROTOCOL_ERROR) > when proxies/frameworks does not subscribe that tunneling mechanism. > > Can you trust that? Note that we would be doing negotiation beforehand using a SETTINGS parameter. Otherwise, a client cannot send a request with `:upgrade:` pseudo header. I believe that a successful negotiation would be sufficient to guarantee that the `:upgrade:` response header will be recognized as a signal (or a 101 status code as a signal). > > / Kari Hurtta > -- Kazuho Oku From nobody Thu Nov 9 23:53:02 2017 Return-Path: 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 611E612EBC6 for ; Thu, 9 Nov 2017 23:53:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8Rj1AJsvxsmz for ; Thu, 9 Nov 2017 23:53:00 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 78D5512EBB9 for ; Thu, 9 Nov 2017 23:52:59 -0800 (PST) Received: from [192.168.178.20] ([93.217.64.237]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MOfQw-1eGtrn2Qa6-0068Qu; Fri, 10 Nov 2017 08:52:53 +0100 To: Patrick McManus , Cory Benfield Cc: HTTP Working Group , hybi References: <150807649389.12130.9191022211105955718.idtracker@ietfa.amsl.com> From: Julian Reschke Message-ID: <773829ab-478a-165e-38c3-023093dd629f@gmx.de> Date: Fri, 10 Nov 2017 08:52:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:1KAAXoUEJ/J6+qgGlJ4WssYObYRsIxh7NCUrIEJUC8Dj3HNWP+p G6MLFry9/lXl5AQpR+bbTjL7usfe5oFg0WY4k6MStZoMq6r8gcPw8svVUK1ikSaTwGZwE9E G1VZo6Y/rf/4Yh5efQcsYkTmDXrnC2BiZYuUptTzOmh5QcuSlbOVUYnfEu9S8imMF5nvh6S yLTZ/8qm7f7Z7iucT2UmQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:D6Uf9RJ52ZU=:nm5YASVZ+mlb/O3PhPwmmQ 2U701Z/FIvr0rHavgz/+YOGBtTELAN+nkgMO9kM8tgvMGNEkGzZR/Emc+HrmRiqLI7gsLdIXg PYiOomTG9WCPoRwkYm6LtE1QnhXJP0q135O4M72a+CgG4lwREPw2WKGlkNRFVpJWe4Lkyxliz vN24bT2oFr10koH0r8hzvYl2Pe4Vljy0IsUjwQWW732e+ck2CpXYRrezooXQgA0N8UW6vlmJZ 8UlID3d09UnqZSuhOOSgRcvyQmV7uq+y5Z3uzkq/OWVSRQoI+h8CzVhIj20AxFRGqnAQm+Htk /kgdEllubwtgl/cJ+WAbDq3CSXbb02blcaKqBff1y4h53Fu1U/UozpQVef5nMhW0oyCLFKwmM kn4EKtPt2wsg6ClkZ9Ks7uFPZGB1w4dZyUjI4hPRg2sP7enqaff/aKrWtT3vh3vwr/6MG6uGS 6g/zMYeMMkq/9ZA5JXNINIgzcKPevabBe/DB9YVzU/5ckz1De3utWZgqJoUWQPU6i0SC06fNz P9YUWyycXGc181n9UHLJ7ho5rW/+w2sREg+NMAWhII7eu2F23azEuArfX+43JuBnr5NZuJ/q9 obAGvhCNGtJV4qRvEO9KsIbfEgPYi4Hn2IohF0lgKe5Dugc3kejvRmjzTP3dDy1PFuPQMVWLe UH6/c1fDlz1R08laQxPQU/K3Pb6OxL017l2trWxoC4kVWn/ncpY/Fx7rn7XZo6IY2toFnd+JN MO1nmawsqkj4PhvMoHtgde1VSToNkw9T68spafdSnY1ZsOEnVZxFy4H2imbi+piXx9Wpqal8O UtJVE+hPKjmgTcOneHQCwql/c8aAtY3ATNCXqAUP2fZ8fRxzdQ= Archived-At: Subject: Re: [hybi] New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 07:53:01 -0000 On 2017-10-15 20:39, Patrick McManus wrote: > > > On Sun, Oct 15, 2017 at 11:43 AM, Cory Benfield > wrote: > > Doesn’t the introduction of a new pseudo-header field violate RFC > 7540 Section 8.1.2.1, which says endpoints MUST NOT generate new > pseudo-header fields? > > Or is the position that that MUST NOT implicitly applies only if > there are no negotiated extensions in use? > > > right - negotiating an extension via 7540 section 5.5 is an opt-in > procedure that lets you do just about anything you agree to.. the spec > tries to draw a bright line between extensions that can be ignored > safely and those that cannot and need to be negotiated (such as this > one). Enjoy the example in there about changing the layout of the > HEADERS frame :). This is also why extensions are hop to hop. > > one of the reasons I chose the pseudo header to only apply to CONNECT is > already very special purpose - so the exception doesn't pollute very far > as a practical matter. > ... But still, it leaks. What if a different extension that wants to co-exist with this one wants to define a pseudo header field with the same name? Best regards, Julian From nobody Fri Nov 10 08:50:28 2017 Return-Path: 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 DC2531289C3 for ; Fri, 10 Nov 2017 08:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 zHFnRMulkz2J for ; Fri, 10 Nov 2017 08:50:24 -0800 (PST) Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E22411279E5 for ; Fri, 10 Nov 2017 08:50:23 -0800 (PST) Received: from souk.fmi.fi (souk.fmi.fi [193.166.211.113]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vAAGoDQ5004840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Nov 2017 18:50:13 +0200 Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id vAAGoC0x027831 ; Fri, 10 Nov 2017 18:50:13 +0200 Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vAAGoCLa026167 ; Fri, 10 Nov 2017 18:50:12 +0200 Received: by shell.siilo.fmi.fi id vAAGoBln026166; Fri, 10 Nov 2017 18:50:11 +0200 Message-Id: <201711101650.vAAGoBln026166@shell.siilo.fmi.fi> In-Reply-To: References: <20171110061456.1349EB532F@welho-filter2.welho.com> To: Kazuho Oku Date: Fri, 10 Nov 2017 18:50:11 +0200 (EET) Sender: hurtta@siilo.fmi.fi From: Kari Hurtta CC: Kari Hurtta , Wenbo Zhu , Patrick McManus , hybi , HTTP Working Group X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171110/28481/01 X-Filter: smtpVgate.fmi.fi: ID 28483/01, 1 parts scanned for known viruses X-Filter: souk.fmi.fi: ID 117820/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Fri, 10 Nov 2017 18:50:13 +0200 (EET) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:50:27 -0000 Kazuho Oku : (Fri Nov 10 09:05:20 2017) > 2017-11-10 15:14 GMT+09:00 Kari Hurtta : > >> 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. > > > >>> Request: > >>> :method: GET > >>> :scheme: https > >>> :authority: server.example.com > >>> :path: /chat > >>> :upgrade: websocket > > > > 8.1.2.1. Pseudo-Header Fields > > https://tools.ietf.org/html/rfc7540#section-8.1.2.1 > > > > states > > > > -------- > > > > Pseudo-header fields are only valid in the context in which they are > > defined. Pseudo-header fields defined for requests MUST NOT appear > > in responses; pseudo-header fields defined for responses MUST NOT > > appear in requests. Pseudo-header fields MUST NOT appear in > > trailers. Endpoints MUST treat a request or response that contains > > undefined or invalid pseudo-header fields as malformed > > (Section 8.1.2.6). > > > > -------- > > > > Then that ":upgrade" works as explicit tunneling mechanism, IF you can trust > > that response is treated as mailformed (stream error of type PROTOCOL_ERROR) > > when proxies/frameworks does not subscribe that tunneling mechanism. > > > > Can you trust that? > > Note that we would be doing negotiation beforehand using a SETTINGS > parameter. Otherwise, a client cannot send a request with `:upgrade:` > pseudo header. > > I believe that a successful negotiation would be sufficient to > guarantee that the `:upgrade:` response header will be recognized as a > signal (or a 101 status code as a signal). Yes, 5.5. Extending HTTP/2 https://tools.ietf.org/html/rfc7540#section-5.5 ----------------- " Extensions that could change the semantics of existing protocol " components MUST be negotiated before being used. ----------------- seems imply that :upgrade pseudo header maut be negotiated. SETTINGS is one possibility: ---------------- " This document doesn't mandate a specific method for negotiating the " use of an extension but notes that a setting (Section 6.5.2) could be " used for that purpose. ---------------- Seems that existing of new pseudo header itself can not be used as negotiation: ---------------- " Extensions are permitted to use new frame types (Section 4.1), new " settings (Section 6.5.2), or new error codes (Section 7). Registries " are established for managing these extension points: frame types " (Section 11.2), settings (Section 11.3), and error codes " (Section 11.4). " " Implementations MUST ignore unknown or unsupported values in all " extensible protocol elements. ---------------- / Kari Hurtta > > > > -- > Kazuho Oku From nobody Fri Nov 10 08:51:31 2017 Return-Path: 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 1C6561205D3 for ; Fri, 10 Nov 2017 08:51:30 -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, HTML_MESSAGE=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=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 rNuMl9KITbbg for ; Fri, 10 Nov 2017 08:51:27 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (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 7B93A12741D for ; Fri, 10 Nov 2017 08:51:27 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id e19so7730957qte.8 for ; Fri, 10 Nov 2017 08:51:27 -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=Thxi64T4JlrOLKMQmH9lbtr0doZ0LpXpsyH524R5kXk=; b=evCUqVIuz63vsRO+mXawRIHr7gI4OdOPxu8PKID+9q5FJFCeLdMpuasYhkb5cbtJ42 oXjsaL1Nzq+EZKkPVDcb4XZvBmIss3vlkpCfJAQ8rWyqs01O8rrizR4/dwYTLZzfOKwe 0HSNTfuZ/yW2iydpW+HYP2BhNG9pjWkZInziQg2ntrELIIDvICSRPErc/yAoDrxDPBoJ uA0BjAUvBL3OYxGskeuTrnNEEGiiLflcXcQhDOnfdklIk0efjItMOo7GLlbzTrl9AJX7 zWy7+7oDy1u8G9z325cgoPb5nI5ez4oK0LIH3xdCI70GbSGj1hYJTZBtetQ8st0G8wuF DUUA== 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=Thxi64T4JlrOLKMQmH9lbtr0doZ0LpXpsyH524R5kXk=; b=UqdRma8E5D4Jk58SfG6MKT/vvLkTLw92s73l+mZ9Evje62xwbqzMK3LgBNdu9I35/o g/yApiXUijiZjZNt9pMjTEdowylZ7FKJ5FMlhmTbF7h7H8vXFJrzjekPWH7IFNiaQLac b/tlJqe+NtIFULz1nxSdirbVySyo7ZVgEVjXkksUuRjDjxl0CqqXLQRLAJecEf4Z+YCN qv59Of1Pej3hifN+1BO1dgdaQjzQMrlgtb2LO9BrAhSj3r+yPPIwI6twWQCAnofpCTRs M95PPxgPPExM2UOa079lg43pjJU0bk2WDSkBe5zdnNBm64/s3N24vMXeHty06+NWFx6r tCYw== X-Gm-Message-State: AJaThX610s2VeKzQ5kORqEkABeZkNRaLmPwJuhDw0TPWz/Rm7zJVVxuN hu8HZ1zTp3zQixc3Pw2rScCpXza1utz2YYBnmI6WbA== X-Google-Smtp-Source: AGs4zMYBGh15nctgvZoNV1X2hSJTaZ1iIWWpOGwRmXpPoLoAr13LPMZ4iLgxkL9J2J8w/sYIve06d0qXWlf1KvcnG0Q= X-Received: by 10.237.36.182 with SMTP id t51mr1591528qtc.90.1510332686390; Fri, 10 Nov 2017 08:51:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.206 with HTTP; Fri, 10 Nov 2017 08:51:05 -0800 (PST) In-Reply-To: References: <20171110061456.1349EB532F@welho-filter2.welho.com> From: Takeshi Yoshino Date: Sat, 11 Nov 2017 01:51:05 +0900 Message-ID: To: Kazuho Oku Cc: Kari Hurtta , hybi , Patrick McManus , HTTP Working Group Content-Type: multipart/alternative; boundary="001a11420b0a44784a055da3bb49" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 16:51:30 -0000 --001a11420b0a44784a055da3bb49 Content-Type: text/plain; charset="UTF-8" On Fri, Nov 10, 2017 at 4:05 PM, Kazuho Oku wrote: > 2017-11-10 15:14 GMT+09:00 Kari Hurtta : > > Then that ":upgrade" works as explicit tunneling mechanism, IF you can > trust > > that response is treated as mailformed (stream error of type > PROTOCOL_ERROR) > > when proxies/frameworks does not subscribe that tunneling mechanism. > > > > Can you trust that? > > Note that we would be doing negotiation beforehand using a SETTINGS > parameter. Otherwise, a client cannot send a request with `:upgrade:` > pseudo header. > > I believe that a successful negotiation would be sufficient to > guarantee that the `:upgrade:` response header will be recognized as a > signal (or a 101 status code as a signal). > Agreed with Kazuho about this point. Depending on such detection of a spec violation is interesting, but I think we shouldn't. It's fragile. We're already clearing the path between the endpoints by the forwarding of the SETTINGS. That should be enough, yes. I'd rather suggest that we don't violate RFC 7540. As we'll be using a pseudo header, we anyway need special logic to generate/parse it. So, it doesn't matter so much whether the name is "upgrade" or not. We could e.g. use ":upgrade", and ":upgrade-response" in each direction respectively. I listed a few more points below that I think we should get consensus. But basically, I like the direction (use of HEADERS, signaling by SETTINGS). ---- I remember that we had some discussion about this kind of usage of the SETTINGS frame mechanism with H2 connection bundling/un-bundling proxies on the way, when we were discussing Yutaka's WS/H2 I-D 3 y ago. Suppose that we have a reverse proxy that has a single H2 connection with a browser which is unbundled by the proxy to different target backends (still H2 but with fewer streams) where some backends can handle tunneling, but some cannot. The proxy needs to either: - forward the SETTINGS to the browser to allow it to use tunneling, but convert tunneling requests to the tunneling/H2 non-capable backends to one over H1 - don't forward the SETTINGS as not all backends are capable of it As SETTINGS is about hop-by-hop characteristics, we need to consolidate the bit as above at bundling points. I think this is fine and we don't want to introduce any complicated mechanism to perform e2e negotiation. Do you all agree on this? ---- In Yutaka's I-D, we tried to allow speculatively initiating a WebSocket over H2 without waiting for capability announcement by the server. In Patrick's proposal, we instead wait for the SETTINGS frame before initiating a WebSocket. How and when should a browser determine whether a certain H2 connection is tunneling capable or not? What's in my mind is: - When there's no connection at all, - ws: RFC 6455 connection attempt is made on TCP but with the HTTP2-Settings header in addition to the standard RFC 6455 headers, which might get upgraded to WS/H2 (indicated by e.g. an additional header, or a special Upgrade value "websocket-h2c") or just proceed as RFC 6455 - wss: Use ALPN? See https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01#section-3.4 - When there's ongoing H2 connection establishing, the browser waits until the initial SETTINGS is received following the preface. If there isn't ENABLE_CONNECT_PROTOCOL, the browser should use WS/TCP. Otherwise, it should use WS/H2. - When there's existing H2 connection established, if there wasn't ENABLE_CONNECT_PROTOCOL in the initial SETTINGS from the server, use WS/TCP, and WS/H2 otherwise. Initially, I thought it might be fine to assume that there's existing H2 when WS attempt is made, but it's not always true, I guess. ---- Is it ok that we cannot announce tunneling capability for each protocol separately? draft-hirano-httpbis-websocket-over-http2-01 allocated a dedicated SETTINGS identifier for WebSockets while draft-hirano-httpbis-websocket-over-http2-00 let each bit indicate capability for each protocol. In Patrick's proposal, currently we just determine tunneling yes/no and then everything beyond is upper layer protocol's work. I think this is fine if this tunneling is made completely independent from the upper layer protocol. --001a11420b0a44784a055da3bb49 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 10, 2017 at 4:05 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
2017-11-10 15:14 GMT+09:00 Kari H= urtta <hurtta-ietf@elmme= -mailer.org>:
> Then that ":upgrade" works as e= xplicit tunneling mechanism, IF you can trust
> that response is treated as mailformed (stream error of type PROTOCOL_= ERROR)
> when proxies/frameworks does not subscribe that tunneling mechanism. >
> Can you trust that?

Note that we would be doing negotiation beforehand using a SETT= INGS
parameter. Otherwise, a client cannot send a request with `:upgrade:`
pseudo header.

I believe that a successful negotiation would be sufficient to
guarantee that the `:upgrade:` response header will be recognized as a
signal (or a 101 status code as a signal).

<= div>Agreed with Kazuho about this point.

Depending= on such detection of a spec violation is interesting, but I think we shoul= dn't. It's fragile. We're already clearing the path between the= endpoints by the forwarding of the SETTINGS. That should be enough, yes.

I'd rather suggest that we don't violate RF= C 7540. As we'll be using a pseudo header, we anyway need special logic= to generate/parse it. So, it doesn't matter so much whether the name i= s "upgrade" or not. We could e.g. use ":upgrade", and &= quot;:upgrade-response" in each direction respectively.

=
I listed a few more points below that I think we should get cons= ensus. But basically, I like the direction (use of HEADERS, signaling by SE= TTINGS).

----

I remember = that we had some discussion about this kind of usage of the SETTINGS frame = mechanism with H2 connection bundling/un-bundling proxies on the way, when = we were discussing=C2=A0Yutaka's WS/H2 I-D=C2=A03 y ago.= =C2=A0

Suppose that we have a reverse proxy that h= as a single H2 connection with a browser which is unbundled by the proxy to= different target backends (still H2 but with fewer streams) where some bac= kends can handle tunneling, but some cannot. The proxy needs to either:
- forward the SETTINGS to the browser to allow it to use tunneling, = but convert tunneling requests to the tunneling/H2 non-capable backends to = one over H1
- don't forward the SETTINGS as not all backends = are capable of it

As SETTINGS is about hop-by-hop = characteristics, we need to consolidate the bit as above at bundling points= . I think this is fine and we don't want to introduce any complicated m= echanism to perform e2e negotiation. Do you all agree on this?
----

In Yutaka's I-D, we tried to= allow speculatively initiating a WebSocket over H2 without waiting for cap= ability announcement by the server. In Patrick's proposal, we instead w= ait for the SETTINGS frame before initiating a WebSocket.

How and when should a browser determine whether a certain H2 connec= tion is tunneling capable or not?

What's in my= mind is:

- When there's no connection at all,=
=C2=A0 - ws: RFC 6455 connection attempt is made on TCP but with= the HTTP2-Settings header in addition to the standard RFC 6455 headers, wh= ich might get upgraded to WS/H2 (indicated by e.g. an additional header, or= a special Upgrade value "websocket-h2c") or just proceed as RFC = 6455
<= div>


--001a11420b0a44784a055da3bb49-- From nobody Fri Nov 10 09:28:33 2017 Return-Path: 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 6429E1289C3 for ; Fri, 10 Nov 2017 09:28:32 -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, HTML_MESSAGE=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=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 R61iAYklMXkn for ; Fri, 10 Nov 2017 09:28:31 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 D2072126CC7 for ; Fri, 10 Nov 2017 09:28:30 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id e19so7872398qte.8 for ; Fri, 10 Nov 2017 09:28:30 -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=W3ZsIqVvB9VGTTYlq92kBPKPodF5WVA7/c/6GNEchvA=; b=AXCefNLDt0tkUXIZrb2Z2fPHMsgKo5cZ63hTY35nYjjEGIC47TTmWdcfCoSv0Q0eIq TpuZ1io1d/XDdmeK9Qilvw0sgMeBV1nN4llh0zk9NkkKT/lhjKjEn120Kw1L+GKBybyn MFQD1GSqmMRJ8nF21/faLEJ0p/RPS0ZRXNnPqax+1TK2IM+xns3Tdxwef7XT8QIvHvm7 WhsXFhFXkZHxDP7tSEqxrha8Bld9YjkhBtWNAR3b8i8HLUJ1vh7NhY/NSOwSqzgIIwGZ HhG9j1SYcGIs3EL9K1jqJSs6iq8bzuVYrCGFRCJZhHmTKK183i+jHK4eupgXBvSr00aB tDIw== 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=W3ZsIqVvB9VGTTYlq92kBPKPodF5WVA7/c/6GNEchvA=; b=M5MEIjgEoZeRHvpiIioLPLMF4YZyAazYeIdZ/s08tV1aoYnUBHUxeJJu7O36aWMsAu wNfqQ/29U5UWIbi6qGravtCIV60WeW9LSQ4+1w8moUoPGxm6v3Zg7c31iLUvh+cQNnQ9 nNCEmw/0d4ErTQiBEcbF55tknKRH0fKM3GtwoTB2EVsQfUfFuhlB9ds6H/47tK9QYgZU 6EBf7iqs+WDBkb3dSFBKr7FAcmBHImmf/OuD7V++IaO7C5o5iONHFRpF5yZgvMg2v4Jd LGyGx9FrL8clF3SDY2KXuFh6eh4r/xnV//GGMKzNLvY7z+gU7ZXiw0IAxNsjLUhNgI4r 0Zlw== X-Gm-Message-State: AJaThX7PQ/WSTvwD38OGXPkoh0yrIi44DdmVCN79KMjOwJYn9jRu7h43 GFHoF3xI3MZZ7h7HAaeKirghmxozCntzVDwDNuzd8w== X-Google-Smtp-Source: AGs4zMZSsesj+kbkXsgJlTBL+oyiCgtELdVHptyStZIWFDzlwUY5YD4o3IsEMrftJgSKBWnAZWoceb7Z6+jsmPVx5NA= X-Received: by 10.200.35.55 with SMTP id a52mr1772594qta.148.1510334909734; Fri, 10 Nov 2017 09:28:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.206 with HTTP; Fri, 10 Nov 2017 09:28:08 -0800 (PST) In-Reply-To: References: <150903901882.24232.14013636670744151147.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Sat, 11 Nov 2017 02:28:08 +0900 Message-ID: To: Patrick McManus Cc: John Fallows , Alexey Melnikov , hybi , HTTP Working Group Content-Type: multipart/alternative; boundary="001a113a7768ca1c9b055da43fa8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:28:32 -0000 --001a113a7768ca1c9b055da43fa8 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 29, 2017 at 10:17 AM, Patrick McManus wrote: > +Alexey > > That interpretation doesn't seem consistent with RFC-6455, section 4.1 >> regarding absolute form (copied below). >> >> *The "Request-URI" part of the request MUST match the /resource* >> * name/ defined in Section 3 (a relative URI) or be an absolute* >> * http/https URI that, when parsed, has a /resource name/, /host/,* >> * and /port/ that match the corresponding ws/wss URI.* >> > > That's really interesting and is the only argument I find at all > compelling.Thanks. Basically its saying that the URI of the GET is not the > websockets URI used in other places such as the cache and the pac. Which is > totally insane imo. > This change happened on draft-ietf-hybi-thewebsocketprotocol-11. I see some arguments saying that it's HTTP/HTTPS until it's upgraded, in some discussion about DNS SRV and cookie handling, which happened before publication of -11. But not sure which of them is really the motivation of the change. --001a113a7768ca1c9b055da43fa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Oct 29, 2017 at 10:17 AM, Patrick McManus <pmcmanus@mozilla.com= > wrote:
+Alexey

That interpretation doesn't seem consi= stent with RFC-6455, section 4.1 regarding absolute form (copied below).

The "Request-URI" part of the requ= est MUST match the /resource
=C2=A0 =C2=A0 =C2=A0 =C2=A0 n= ame/ defined in Section 3 (a relative URI) or be an absolute
=C2=A0 =C2=A0 =C2=A0 =C2=A0 http/https URI that, when pars= ed, has a /resource name/, /host/,
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 and /port/ that match the corresponding ws/wss URI.
<= /div>

That's really = interesting and is the only argument I find at all compelling.Thanks.=C2=A0= Basically its saying that the URI of the GET is not the websockets URI use= d in other places such as the cache and the pac. Which is totally insane im= o.

This chang= e happened on=C2=A0draft-ietf-hybi-thewebsocketprotocol-11. I see some argu= ments saying that it's HTTP/HTTPS until it's upgraded, in some disc= ussion about DNS SRV and cookie handling, which happened before publication= of -11. But not sure which of them is really the motivation of the change.=
=C2=A0
--001a113a7768ca1c9b055da43fa8-- From nobody Fri Nov 10 09:52:07 2017 Return-Path: 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 ED19812EC88 for ; Fri, 10 Nov 2017 09:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 mBi0uklAlZ3C for ; Fri, 10 Nov 2017 09:52:04 -0800 (PST) Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEB612EC79 for ; Fri, 10 Nov 2017 09:52:03 -0800 (PST) Received: from souk.fmi.fi (souk.fmi.fi [193.166.211.113]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vAAHpr1P014050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Nov 2017 19:51:53 +0200 Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id vAAHprT4001681 ; Fri, 10 Nov 2017 19:51:53 +0200 Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vAAHpr9B031732 ; Fri, 10 Nov 2017 19:51:53 +0200 Received: by shell.siilo.fmi.fi id vAAHpqHC031731; Fri, 10 Nov 2017 19:51:52 +0200 Message-Id: <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> In-Reply-To: References: <20171110061456.1349EB532F@welho-filter2.welho.com> To: Takeshi Yoshino Date: Fri, 10 Nov 2017 19:51:52 +0200 (EET) Sender: hurtta@siilo.fmi.fi From: Kari Hurtta CC: Kazuho Oku , Kari Hurtta , hybi , Patrick McManus , HTTP Working Group X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171110/28661/01 X-Filter: smtpVgate.fmi.fi: ID 28663/01, 1 parts scanned for known viruses X-Filter: souk.fmi.fi: ID 117954/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Fri, 10 Nov 2017 19:51:54 +0200 (EET) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 17:52:06 -0000 Takeshi Yoshino : (Fri Nov 10 18:51:05 2017) > Suppose that we have a reverse proxy that has a single H2 connection with a > browser which is unbundled by the proxy to different target backends (still > H2 but with fewer streams) where some backends can handle tunneling, but > some cannot. The proxy needs to either: > - forward the SETTINGS to the browser to allow it to use tunneling, but > convert tunneling requests to the tunneling/H2 non-capable backends to one > over H1 > - don't forward the SETTINGS as not all backends are capable of it > > As SETTINGS is about hop-by-hop characteristics, we need to consolidate the > bit as above at bundling points. I think this is fine and we don't want to > introduce any complicated mechanism to perform e2e negotiation. Do you all > agree on this? SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server end of connection to client end of connection tells on that case that server end of connection understand :upgrade pseudo header. It tells nothing about that what is behind of that server end of connection. Only after request is sent, http response tells if that authority and path supporting that upgrade. Error is reported as http status code. I see that reverse proxy can send SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) even when it does not konw if next hop supports that. Support of next hop or origin server is reported by when that protocol is triedm failure is reported on http status code. I assume that that SETTINGS is send on initial server settings (connection preface SETTINGS). / Kari Hurtta From nobody Fri Nov 10 10:10:35 2017 Return-Path: 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 5872A12ECC6 for ; Fri, 10 Nov 2017 10:10:34 -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, HTML_MESSAGE=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=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 6bWhFm-EOuDr for ; Fri, 10 Nov 2017 10:10:32 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 AC24212ECC4 for ; Fri, 10 Nov 2017 10:10:32 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id p44so2389054qtj.6 for ; Fri, 10 Nov 2017 10:10:32 -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=igNI4fUO11seh6nOh4gji1DWvd88pdAv+7BMWkRoaJc=; b=OHTuX4jCViJcDsrCnvRmLUIPWHO7JQzqm1d6C/o02U8C0RBg1ytR62o8+StiUzWi/S V8S3GFfeZm9aXymO7cs37pZP2GN5q6Gmj+PoYET0LQ/xFzppgCKp+XG/feDJX8AjRIm7 BeNkZElo3Mo1iBRKgOkXTt4IhZdwPD31pAt376nHCHzeOCBOqFEDQJTbf1UCTm+IkTse PW6VhrxG21gSmijTV6HI/7gXi6gFkWx2IBuK9L6vDSLtdDVoXD/jwD8vd1t22pvZq0h7 +Qt/ZvwijkPxzXfP3YDG31+GNj1/iDw9Q/55JP8lFLVXcNAy1ZFGT241zxhtCEhCZeE2 yNKA== 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=igNI4fUO11seh6nOh4gji1DWvd88pdAv+7BMWkRoaJc=; b=G8VlCZRWgsAjLtKf9OrmlC/oKuiGQsb75ttx3S6fnM4Q3TM749OLinslPLTj1IkwNO 03fJJ1Kc9kpC1ov8+260rUokMVEBI9+Y2KwNx9OVUkgbsO+qJjQw5HzT78RF7fDcpb5x Q5mtJaw51wtEqM0ztxqL+3OQjNoEAT80jmVm3RmTUtBZoJwh7r41kCvs5iuwbnHhSBr5 uuB91pJsQZV/5cpa/iHlT1Fal411Hvr0zSx73IIJ41o/u53IWyk4fcnBiVgRBYRY+IMH ypDCS50/M8Rpz9q8gDz4jnT6B6oRU+/PiW51BOe83+j7GJPdgAKQagxXFKOuqrOJmjJD 7Hcw== X-Gm-Message-State: AJaThX5H6nCYH/zKyuP7SBP9N6ZLMkXrXW7fdXeYNGnXQZtJIPCljBPU GFbQpEWacw5TEn+eOtyz+tx0QMzrtQaVAWBKc50vYQ== X-Google-Smtp-Source: AGs4zMbUdqIH3XIt10UzmgkPvpbsVNufD2VumR9iaMXVKz/0i6EITlVQfN2YRfyKoTBmiOA9r4lzjLGhLfJHmpaN5BA= X-Received: by 10.237.42.27 with SMTP id c27mr2094006qtd.282.1510337431630; Fri, 10 Nov 2017 10:10:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.149.206 with HTTP; Fri, 10 Nov 2017 10:10:10 -0800 (PST) In-Reply-To: <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> References: <20171110061456.1349EB532F@welho-filter2.welho.com> <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> From: Takeshi Yoshino Date: Sat, 11 Nov 2017 03:10:10 +0900 Message-ID: To: Kari Hurtta Cc: Kazuho Oku , hybi , Patrick McManus , HTTP Working Group Content-Type: multipart/alternative; boundary="001a114448641b1ac4055da4d600" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Nov 2017 18:10:34 -0000 --001a114448641b1ac4055da4d600 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 11, 2017 at 2:51 AM, Kari Hurtta wrote: > SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server > end of connection to client end of connection tells on that case > > that server end of connection understand > :upgrade > pseudo header. > > It tells nothing about that what is behind of that server end of > connection. > > Only after request is sent, http response tells if that authority > and path supporting that upgrade. Error is reported as http status code. > > I see that reverse proxy can send SETTINGS ENABLE_UPGRADE (or > ENABLE_CONNECT_PROTOCOL) > even when it does not konw if next hop supports that. Support > of next hop or origin server is reported by when that protocol > is triedm failure is reported on http status code. > Ideally I want to allow a browser to know as much as possible info about the capability of the path with less speculative attempts, for less fallback. So, I investigated this situation and explored how much info we could give to the SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL). But yes, the tool, "SETTINGS", we have is only about the peer end of a connection. I think it does make sense to just follow that principle. We can build the opt-in mechanism by that for each hop, and then, proxies are still allowed to emit errors on capability mismatch between connections, as you said. We could design error code, fallback, etc. for this kind of cases if it turns out we really need to take care of. For the initial implementation, maybe we could just let browsers give up when a connection attempt fails on a connection with ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced. --001a114448641b1ac4055da4d600 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= at, Nov 11, 2017 at 2:51 AM, Kari Hurtta <hurtta-ietf@elmme-mai= ler.org> wrote:
SETTINGS=C2= =A0 =C2=A0ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server
end of connection to client end of connection tells on that case

that server end of connection understand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 :upgrade
pseudo header.

It tells nothing about that what is behind of that server end of connection= .

Only after request is sent, http response tells if that authority
and path supporting that upgrade. Error is reported as http status code.
I see that reverse proxy can send SETTINGS=C2=A0 =C2=A0ENABLE_UPGRADE (or E= NABLE_CONNECT_PROTOCOL)
even when it does not konw if next hop supports that. Support
of next hop or origin server is reported by when that protocol
is triedm failure is reported on http status code.
Ideally I want to allow a browser to know as much as possible i= nfo about the capability of the path with less speculative attempts, for le= ss fallback. So, I investigated this situation and explored how much info w= e could give to the SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL).

But yes, the tool, "SETTINGS", we have is= only about the peer end of a connection. I think it does make sense to jus= t follow that principle. We can build the opt-in mechanism by that for each= hop, and then, proxies are still allowed to emit errors on capability mism= atch between connections, as you said.

We could de= sign error code, fallback, etc. for this kind of cases if it turns out we r= eally need to take care of. For the initial implementation, maybe we could = just let browsers give up when a connection attempt fails on a connection w= ith ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced.
=C2=A0=
--001a114448641b1ac4055da4d600-- From nobody Fri Nov 10 23:47:03 2017 Return-Path: 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 B1360126CF6 for ; Fri, 10 Nov 2017 23:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 Bb2XZmuDAAAV for ; Fri, 10 Nov 2017 23:47:00 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 0578B120726 for ; Fri, 10 Nov 2017 23:47:00 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 4so192210pge.1 for ; Fri, 10 Nov 2017 23:46:59 -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=vKHYnLB/kakIbPzNxb1ScOoGX9wmkZMbhe9mlzK9+pE=; b=FiO+Bm9jtyQc3I+Nnc8W1UWX78QTsOEFqRL/v7l9DmK7mAE+akZU6Nr4oyOmBoqVca N19oepqi86vuTTuBbPrdpwGBkeJP32Uo0B55DU9SoYlr8evYn16X3zMoQC2YVbGjr3jP DdcqcgZ6WX7IfJcdmvoCFQBGh2QWEKlhqBiM1895jSx0QP6sIdpxMweRjc1KM1jaajFR 2avKWYG9FIUYr5Xuf4qzqhhUSHj57dxv/IQ4QIMjGrMYi8ywQsdOP2x/6KRJQzgBuY5l vLFhhbbvlKfL8X98xXS0TZ9ykhNNysqr6xhFvLv6WlUgEdrkdMC/3QhntBC1ADI+Fx6o wXsw== 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=vKHYnLB/kakIbPzNxb1ScOoGX9wmkZMbhe9mlzK9+pE=; b=J5jRpM8Lg1IrTh6Musui+cPFX5/wGgW4zBUJuCGOBpFO6LR5YTGjUEak5f4R/DB5SM 3nKTu0Ss+2QJDWiL/YEJDnt/Fv+IJs1fQaym9bxn/1qkUEpAuoiXQbNRzgAMEpps7TOr ZZDc/Yd6JC00+sj43eRVToJ/T9DEbKu3+k8RtnhWFKaO8kK31EtJk+4o83BZsVwcZnPE 1uRbisCffQhlNsKp+VPT1qzxJ8flT/kxot6IvxBm4jIDxJ0lyt74EVFaVH7gN+xiUJuh xvj3pAId1V7g5Dd7mhUy+OAuW215pbiMevEefeRG6ncuIikFWpxLDXOmsgD1oQ3GQcyB J4Ng== X-Gm-Message-State: AJaThX5BKubBsWQoUx+a15fqA9rBBa2LXrqEo7El99p6B9Ax8v4deLRF fk2fcqarh/TYDN//cEO2+Gvqasii72zfSarPhpc= X-Google-Smtp-Source: AGs4zMbLUM5k2IHii344WlbX6B0Xvq1t5KWXhTh3di35t6kl9xCR5+YsSC3MofaD0JFasKGaviPVgFRxPR9cQuy65M0= X-Received: by 10.84.171.195 with SMTP id l61mr2861404plb.27.1510386419555; Fri, 10 Nov 2017 23:46:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.159.9 with HTTP; Fri, 10 Nov 2017 23:46:58 -0800 (PST) In-Reply-To: References: <20171110061456.1349EB532F@welho-filter2.welho.com> <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> From: Kazuho Oku Date: Sat, 11 Nov 2017 15:46:58 +0800 Message-ID: To: Takeshi Yoshino Cc: Kari Hurtta , hybi , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 07:47:02 -0000 2017-11-11 2:10 GMT+08:00 Takeshi Yoshino : > On Sat, Nov 11, 2017 at 2:51 AM, Kari Hurtta > wrote: >> >> SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server >> end of connection to client end of connection tells on that case >> >> that server end of connection understand >> :upgrade >> pseudo header. >> >> It tells nothing about that what is behind of that server end of >> connection. >> >> Only after request is sent, http response tells if that authority >> and path supporting that upgrade. Error is reported as http status code. >> >> I see that reverse proxy can send SETTINGS ENABLE_UPGRADE (or >> ENABLE_CONNECT_PROTOCOL) >> even when it does not konw if next hop supports that. Support >> of next hop or origin server is reported by when that protocol >> is triedm failure is reported on http status code. > > > Ideally I want to allow a browser to know as much as possible info about the > capability of the path with less speculative attempts, for less fallback. > So, I investigated this situation and explored how much info we could give > to the SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL). > > But yes, the tool, "SETTINGS", we have is only about the peer end of a > connection. I think it does make sense to just follow that principle. We can > build the opt-in mechanism by that for each hop, and then, proxies are still > allowed to emit errors on capability mismatch between connections, as you > said. > > We could design error code, fallback, etc. for this kind of cases if it > turns out we really need to take care of. For the initial implementation, > maybe we could just let browsers give up when a connection attempt fails on > a connection with ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced. I agree. While I agree that having a status code that indicates failure to upgrade the connection "end-to-end" might be a nice idea, I would also argue that the necessity is not specific to HTTP/2. We could have had a connection-cannot-be-upgraded status code for HTTP/1.1. But in reality, we do not have such a status code, and nobody has argue for having that (as I know of). Considering the fact, I would anticipate that we will be fine without adding a new status code to indicate such failure. -- Kazuho Oku From nobody Sat Nov 11 01:19:57 2017 Return-Path: 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 783BA129418 for ; Sat, 11 Nov 2017 01:19:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 NY73PeM_D7BE for ; Sat, 11 Nov 2017 01:19:52 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FAB12420B for ; Sat, 11 Nov 2017 01:19:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 5F294B51FC; Sat, 11 Nov 2017 11:19:49 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id hrnN1VDmowYv; Sat, 11 Nov 2017 11:19:47 +0200 (EET) Received: from localhost (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPS id 1D41221C; Sat, 11 Nov 2017 11:19:41 +0200 (EET) In-Reply-To: References: To: HTTP Working Group Date: Sat, 11 Nov 2017 11:19:41 +0200 (EET) Sender: hurtta@[192.168.0.26] From: Kari Hurtta CC: HYBI Working Group , Patrick McManus , Amos Jeffries , Kari Hurtta X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171111091949.5F294B51FC@welho-filter2.welho.com> Archived-At: Subject: [hybi] proxy & ENABLE_UPGRADE SETTINGS | Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 09:19:55 -0000 > SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server > end of connection to client end of connection tells on that case > > that server end of connection understand > :upgrade > pseudo header. > > It tells nothing about that what is behind of that server end of > connection. > > Only after request is sent, http response tells if that authority > and path supporting that upgrade. Error is reported as http status code. > > I see that reverse proxy can send SETTINGS ENABLE_UPGRADE (or > ENABLE_CONNECT_PROTOCOL) > even when it does not konw if next hop supports that. Support > of next hop or origin server is reported by when that protocol > is triedm failure is reported on http status code. Amos Jeffries wrote: > A proxy that sends that ENABLE_UPGRADE is guaranteeing that it *will* > service the upgrade and handle the resulting traffic syntax. By itself > if necessary. I ligthly disagreed. ENABLE_UPGRADE just tells that :upgrade is not considered to be error which causes stream error of type PROTOCOL_ERROR emitted and tells possible full duplex handling (as was on :method = CONNECT). You can also try Upgrade: on HTTP/1.1 and server or proxy have permission to ignore it. Upgrade is just suggestion from client. In that case request is processed as upgrade is not done. It can still succeed (without protocol change) or fail as any http request can. > In the general case a proxy that negotiates a SETTING it cannot > guarantee support for is broken. It must instead negotiate a SETTINGS > without the feature and re-negotiate with another SETTINGS later when it > has better information. / Kari Hurtta From nobody Sat Nov 11 02:45:29 2017 Return-Path: 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 277ED1294E8 for ; Sat, 11 Nov 2017 02:45:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 GIM0De4BO2lK for ; Sat, 11 Nov 2017 02:45:24 -0800 (PST) Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B81301294E6 for ; Sat, 11 Nov 2017 02:45:23 -0800 (PST) Received: from basaari.fmi.fi (basaari.fmi.fi [193.166.211.14]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vABAjDJC018118 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Nov 2017 12:45:13 +0200 Received: from shell.siilo.fmi.fi by basaari.fmi.fi with ESMTP id vABAjDg6003143 ; Sat, 11 Nov 2017 12:45:13 +0200 Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vABAjDcp027389 ; Sat, 11 Nov 2017 12:45:13 +0200 Received: by shell.siilo.fmi.fi id vABAjCvK027388; Sat, 11 Nov 2017 12:45:12 +0200 Message-Id: <201711111045.vABAjCvK027388@shell.siilo.fmi.fi> In-Reply-To: References: <20171110061456.1349EB532F@welho-filter2.welho.com> <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> To: Kazuho Oku Date: Sat, 11 Nov 2017 12:45:12 +0200 (EET) Sender: hurtta@siilo.fmi.fi From: Kari Hurtta CC: Takeshi Yoshino , Kari Hurtta , hybi , Patrick McManus , HTTP Working Group X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171111/38395/01 X-Filter: smtpVgate.fmi.fi: ID 38397/01, 1 parts scanned for known viruses X-Filter: basaari.fmi.fi: ID 162806/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Sat, 11 Nov 2017 12:45:14 +0200 (EET) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 10:45:26 -0000 Kazuho Oku : (Sat Nov 11 09:46:58 2017) <...> > > We could design error code, fallback, etc. for this kind of cases if it > > turns out we really need to take care of. For the initial implementation, > > maybe we could just let browsers give up when a connection attempt fails on > > a connection with ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced. > > I agree. > > While I agree that having a status code that indicates failure to > upgrade the connection "end-to-end" might be a nice idea, I would also > argue that the necessity is not specific to HTTP/2. > > We could have had a connection-cannot-be-upgraded status code for > HTTP/1.1. But in reality, we do not have such a status code, and > nobody has argue for having that (as I know of). There is (sort of) 426 Upgrade Required normally, if Upgrade can not done, http request is processed without protocol change. This status code allows refusing of processing. 426 Upgrade Required is defined on RFC 2817: Upgrading to TLS Within HTTP/1.1 https://tools.ietf.org/html/rfc2817 Yes, that status code is for somewhat different purpose. > Considering the fact, I would anticipate that we will be fine without > adding a new status code to indicate such failure. > > -- > Kazuho Oku / Kari Hurtta From nobody Sat Nov 11 06:17:12 2017 Return-Path: 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 3EEC61200E5 for ; Sat, 11 Nov 2017 06:17:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.107 X-Spam-Level: X-Spam-Status: No, score=-1.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 JKMkPQ0hqrEZ for ; Sat, 11 Nov 2017 06:17:09 -0800 (PST) Received: from treenet.co.nz (unknown [121.99.228.82]) by ietfa.amsl.com (Postfix) with ESMTP id BEFF412009C for ; Sat, 11 Nov 2017 06:17:07 -0800 (PST) Received: from [192.168.137.92] (unknown [121.98.43.66]) by treenet.co.nz (Postfix) with ESMTPA id 1FC00660057; Sun, 12 Nov 2017 03:17:02 +1300 (NZDT) To: Kari Hurtta , HTTP Working Group Cc: HYBI Working Group , Patrick McManus References: <20171111091949.5F294B51FC@welho-filter2.welho.com> From: Amos Jeffries Message-ID: Date: Sun, 12 Nov 2017 03:17:01 +1300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20171111091949.5F294B51FC@welho-filter2.welho.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [hybi] proxy & ENABLE_UPGRADE SETTINGS | Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 14:17:11 -0000 On 11/11/17 22:19, Kari Hurtta wrote: >> SETTINGS ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) from server >> end of connection to client end of connection tells on that case >> >> that server end of connection understand >> :upgrade >> pseudo header. >> >> It tells nothing about that what is behind of that server end of >> connection. >> >> Only after request is sent, http response tells if that authority >> and path supporting that upgrade. Error is reported as http status code. >> >> I see that reverse proxy can send SETTINGS ENABLE_UPGRADE (or >> ENABLE_CONNECT_PROTOCOL) >> even when it does not konw if next hop supports that. Support >> of next hop or origin server is reported by when that protocol >> is triedm failure is reported on http status code. > > Amos Jeffries wrote: > >> A proxy that sends that ENABLE_UPGRADE is guaranteeing that it *will* >> service the upgrade and handle the resulting traffic syntax. By itself >> if necessary. > > I ligthly disagreed. > > ENABLE_UPGRADE just tells that :upgrade is not considered to > be error which causes stream error of type PROTOCOL_ERROR > emitted and tells possible full duplex handling (as was on > :method = CONNECT). > > You can also try Upgrade: on HTTP/1.1 and server or proxy > have permission to ignore it. Upgrade is just suggestion > from client. If ":upgrade" has the same optional nature as Upgrade did there is zero point in creating it. Just use the existing Upgrade header in the HEADERS frame. That does not require any negotiation. The whole point of SETTINGS is to promise the recipient of that frame that the things mentioned in it will work. No maybes or guessing. This guarantee provided by SETTINGS is one of the ways HTTP/2 improves over HTTP/1.1. No more sending maybe-ignored headers and hoping for success a few RTT later. The client can know up front whether that connection is a usable channel for the negotiable feature or not. ... > >> In the general case a proxy that negotiates a SETTING it cannot >> guarantee support for is broken. It must instead negotiate a SETTINGS >> without the feature and re-negotiate with another SETTINGS later when it >> has better information. > > / Kari Hurtta > > From nobody Sat Nov 11 07:50:28 2017 Return-Path: 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 8B8FE129ACC for ; Sat, 11 Nov 2017 07:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 2_MFIyKQ-pnQ for ; Sat, 11 Nov 2017 07:50:23 -0800 (PST) Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B55EF129A90 for ; Sat, 11 Nov 2017 07:50:22 -0800 (PST) Received: from basaari.fmi.fi (basaari.fmi.fi [193.166.211.14]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vABFoB5S028288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Nov 2017 17:50:11 +0200 Received: from shell.siilo.fmi.fi by basaari.fmi.fi with ESMTP id vABFoBHs000963 ; Sat, 11 Nov 2017 17:50:11 +0200 Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vABFoBue022552 ; Sat, 11 Nov 2017 17:50:11 +0200 Received: by shell.siilo.fmi.fi id vABFo8kw022551; Sat, 11 Nov 2017 17:50:08 +0200 Message-Id: <201711111550.vABFo8kw022551@shell.siilo.fmi.fi> In-Reply-To: References: <20171111091949.5F294B51FC@welho-filter2.welho.com> To: Amos Jeffries Date: Sat, 11 Nov 2017 17:50:08 +0200 (EET) Sender: hurtta@siilo.fmi.fi From: Kari Hurtta CC: Kari Hurtta , HTTP Working Group , HYBI Working Group , Patrick McManus X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171111/39224/01 X-Filter: smtpVgate.fmi.fi: ID 39226/01, 1 parts scanned for known viruses X-Filter: basaari.fmi.fi: ID 164217/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Sat, 11 Nov 2017 17:50:14 +0200 (EET) Archived-At: Subject: Re: [hybi] proxy & ENABLE_UPGRADE SETTINGS | Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 15:50:27 -0000 Amos Jeffries : (Sat Nov 11 16:17:01 2017) >> >> ENABLE_UPGRADE just tells that :upgrade is not considered to >> be error which causes stream error of type PROTOCOL_ERROR >> emitted and tells possible full duplex handling (as was on >> :method = CONNECT). >> >> You can also try Upgrade: on HTTP/1.1 and server or proxy >> have permission to ignore it. Upgrade is just suggestion >> from client. > > If ":upgrade" has the same optional nature as Upgrade did there is zero > point in creating it. Just use the existing Upgrade header in the > HEADERS frame. That does not require any negotiation. Wrong. HTTP/2 does not support Upgrade, therefore it needs negotiation. 8.1.2.2. Connection-Specific Header Fields https://tools.ietf.org/html/rfc7540#section-8.1.2.2 " HTTP/2 does not use the Connection header field to indicate " connection-specific header fields; in this protocol, connection- " specific metadata is conveyed by other means. An endpoint MUST NOT " generate an HTTP/2 message containing connection-specific header " fields; any message containing connection-specific header fields MUST " be treated as malformed (Section 8.1.2.6). And " Note: HTTP/2 purposefully does not support upgrade to another " protocol. The handshake methods described in Section 3 are " believed sufficient to negotiate the use of alternative protocols. Indication that Upgrade: is "upgrade HTTP/2 stream to tunnel of another protocol" need negotiation. HTTP/1.1 Upgrade: is "upgrade connection to another protocol". > The whole point of SETTINGS is to promise the recipient of that frame > that the things mentioned in it will work. No maybes or guessing. Point of SETTINGS is to promise that that frame is interepreted accoding of new specification and not accoding of RFC 7540 which means "stream error (Section 5.4.2) of type PROTOCOL_ERROR". That is treatment of ":upgrade" pseudo header and "Upgrade" connection header according of RFC 7540. SETTINGS can not promise anything about next hops on multihop environment when there is several upstream targets. You can NOT know that there is Websocket on particular :path bofore you know this path. SETTINGS can not tell that. Ability to do Upgrade to websocket is granularity of URL path. If you change URL path then may be that Upgrade is not possible. / Kari Hurtta From nobody Sat Nov 11 11:30:44 2017 Return-Path: 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 52566124239 for ; Sat, 11 Nov 2017 11:30:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 qwtwHxSJ8UMF for ; Sat, 11 Nov 2017 11:30:39 -0800 (PST) Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80034126BF0 for ; Sat, 11 Nov 2017 11:30:37 -0800 (PST) Received: from basaari.fmi.fi (basaari.fmi.fi [193.166.211.14]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vABJUMep026545 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Nov 2017 21:30:22 +0200 Received: from shell.siilo.fmi.fi by basaari.fmi.fi with ESMTP id vABJUMKI014040 ; Sat, 11 Nov 2017 21:30:22 +0200 Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vABJUMAT010068 ; Sat, 11 Nov 2017 21:30:22 +0200 Received: by shell.siilo.fmi.fi id vABJUJKu010067; Sat, 11 Nov 2017 21:30:19 +0200 Message-Id: <201711111930.vABJUJKu010067@shell.siilo.fmi.fi> In-Reply-To: References: <20171111091949.5F294B51FC@welho-filter2.welho.com> To: Amos Jeffries Date: Sat, 11 Nov 2017 21:30:19 +0200 (EET) Sender: hurtta@siilo.fmi.fi From: Kari Hurtta CC: Kari Hurtta , HTTP Working Group , HYBI Working Group , Patrick McManus X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171111/39802/01 X-Filter: smtpVgate.fmi.fi: ID 39804/01, 1 parts scanned for known viruses X-Filter: basaari.fmi.fi: ID 165271/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Sat, 11 Nov 2017 21:30:26 +0200 (EET) Archived-At: Subject: [hybi] SETTINGS ENABLE_WEBSOCKET ?? | Re: proxy & ENABLE_UPGRADE SETTINGS | Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Nov 2017 19:30:42 -0000 Amos Jeffries : (Sat Nov 11 16:17:01 2017) > If ":upgrade" has the same optional nature as Upgrade did there is zero > point in creating it. Just use the existing Upgrade header in the > HEADERS frame. That does not require any negotiation. > > > The whole point of SETTINGS is to promise the recipient of that frame > that the things mentioned in it will work. No maybes or guessing. > > This guarantee provided by SETTINGS is one of the ways HTTP/2 improves > over HTTP/1.1. No more sending maybe-ignored headers and hoping for > success a few RTT later. The client can know up front whether that > connection is a usable channel for the negotiable feature or not. > Sidenote: If you want SETTINGS to tell that websocket can be used over HTTP/2 then :upgrade = and SETTINGS ENABLE_UPGRADE is no go. No general tunneling as Kazuho Oku as suggesting in that thread: https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0209.html > 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. In that case SETTINGS ENABLE_UPGRADE tells nothing what upgrades are available (or you need to do registry for different 32-bit values of ENABLE_UPGRADE to map possible upgrade protocols). Same to say about SETTINGS ENABLE_CONNECT_PROTOCOL and :protocol = You are asking SETTINGS ENABLE_WEBSOCKET then and that is not proposed on draft-mcmanus-httpbis-h2-websockets-01 either. / Kari Hurtta From nobody Sat Nov 11 16:31:49 2017 Return-Path: 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 952921274D0 for ; Sat, 11 Nov 2017 16:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 q5KR37I84Wat for ; Sat, 11 Nov 2017 16:31:46 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 BF11012704A for ; Sat, 11 Nov 2017 16:31:46 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id n89so9301143pfk.11 for ; Sat, 11 Nov 2017 16:31:46 -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=ycm0ggjwUVJ0RWmm0sU3mShfuS6mVYp29iuhYFS0LzA=; b=RYzhw5mzdcdp7zQdMU10Sle3+hKAggEUHncSkX9LsY5rgFqZAptxFzdZwry40ECNgJ Z1wUYOYPQ09HeA+WlNNKOeUbzbWLq/JMoqMTKya+LPRdYUd7qPECdur38b+vQIOhbaLK MEZQZ+kaGN42xVKI5EP+TxafmHZ6zvMgWaEFKYgfRu5RSpAkYntelEWmb/2jQmmN3Lac TtoAri4kt4IoJZ1umjAQ/OslTaPfREPR131FRK/pvlHnt4w2NnvM4wjiwv1CQOh0L8ZP pbkrYUF7ZF84vDrizdXfVCApnI32g3OW3yOZZIKayHuzK1GTq1Ks2J8yhhxxWVeyc32i mfLA== 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=ycm0ggjwUVJ0RWmm0sU3mShfuS6mVYp29iuhYFS0LzA=; b=HDhRastFI5UKevQIu+i6KVQRfwubZrVIFk7Wy6YnQN2pIXXzoRNi4NtAa+sZclCxzV vX4ZHimbSmXP/VRO+6vbpmroffrVaA1AxWWHtGG6+6IbvyapBdhrTsMgUZwnEB2zLB7T KDPmSYcLlWs9EG+dZBQSv7bQ71O3JrB2bBZzrgVyC/fFMbrwq3F4333DhEQcGJ2pYaMx 3So/7DJ0Qc+TZofngQnLb1LdfgGYkREH8d5uMTAAQXJeEnOjhJJ8ChTCQ70B2HjjUmyq C5uGs0zhCe/1gjGsxDetR5vl7/fut5e2qHy2/kcw5fbnbIsiivYhxULNrgEOE2tRU6b3 jLnA== X-Gm-Message-State: AJaThX4Tg0wwg2FPVU4x3aEgGoYkYOD+3f1bbboqw+FCeXKhcQsBtXIt M0ZHpbkfwLpIIqhFUO2r7OBcvDXo5SE+Tlv2Kng= X-Google-Smtp-Source: AGs4zMY3f/gRAzvcNV1zFQ3HQnxvGk0jmmJqzc1jvSQ5uZP9ZkJ2luw4SgdKtLX+r/kIU2NnVBy1uTGzewNRVPQa7fo= X-Received: by 10.99.112.23 with SMTP id l23mr4516646pgc.277.1510446706361; Sat, 11 Nov 2017 16:31:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.159.9 with HTTP; Sat, 11 Nov 2017 16:31:45 -0800 (PST) In-Reply-To: <201711111045.vABAjCvK027388@shell.siilo.fmi.fi> References: <20171110061456.1349EB532F@welho-filter2.welho.com> <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> <201711111045.vABAjCvK027388@shell.siilo.fmi.fi> From: Kazuho Oku Date: Sun, 12 Nov 2017 08:31:45 +0800 Message-ID: To: Kari Hurtta Cc: Takeshi Yoshino , hybi , Patrick McManus , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 00:31:48 -0000 Hi, 2017-11-11 18:45 GMT+08:00 Kari Hurtta : > Kazuho Oku : (Sat Nov 11 09:46:58 2017) > <...> >> > We could design error code, fallback, etc. for this kind of cases if it >> > turns out we really need to take care of. For the initial implementation, >> > maybe we could just let browsers give up when a connection attempt fails on >> > a connection with ENABLE_UPGRADE (or ENABLE_CONNECT_PROTOCOL) announced. >> >> I agree. >> >> While I agree that having a status code that indicates failure to >> upgrade the connection "end-to-end" might be a nice idea, I would also >> argue that the necessity is not specific to HTTP/2. >> >> We could have had a connection-cannot-be-upgraded status code for >> HTTP/1.1. But in reality, we do not have such a status code, and >> nobody has argue for having that (as I know of). > > There is (sort of) > > 426 Upgrade Required > > > normally, if Upgrade can not done, http request is processed without protocol > change. This status code allows refusing of processing. > > 426 Upgrade Required > > is defined on > > RFC 2817: Upgrading to TLS Within HTTP/1.1 > https://tools.ietf.org/html/rfc2817 > > > Yes, that status code is for somewhat different purpose. Thank you for pointing that out. My view is that 426 is a status code that instructs a client to upgrade the connection (or a stream). I do not think that it would be the status code that we can use for telling the client that the stream could not be upgraded even though the client requested the upgrade. > >> Considering the fact, I would anticipate that we will be fine without >> adding a new status code to indicate such failure. >> >> -- >> Kazuho Oku > > / Kari Hurtta > -- Kazuho Oku From nobody Sat Nov 11 20:41:39 2017 Return-Path: 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 122CF126C0F for ; Sat, 11 Nov 2017 20:41:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.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 pOmu-mAiTCpv for ; Sat, 11 Nov 2017 20:41:28 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0113.outbound.protection.outlook.com [104.47.41.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4CF128BA2 for ; Sat, 11 Nov 2017 20:41:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ltR21dd/eXufj4UDMu6EDPN+4oDaRrJg6B7HKGy2Yv4=; b=guqgR785wtQLvagKL16qnNfOz6vT1fsQZlbf+mThTpwM7t+waqSbnuqEntYeOuLFkYk8S/U4SEkPwnPb+XUaeaeJ9A1A3wd59pW0oxHBRPnI/isfPOVFHx8XsWRgMFL+MVLC4vI6RtkqDSosovqikD92p0sIPqAJyXcCkTvGHyY= Received: from MWHPR08MB3472.namprd08.prod.outlook.com (10.164.203.35) by MWHPR08MB3471.namprd08.prod.outlook.com (10.164.203.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.218.12; Sun, 12 Nov 2017 04:41:26 +0000 Received: from MWHPR08MB3472.namprd08.prod.outlook.com ([10.164.203.35]) by MWHPR08MB3472.namprd08.prod.outlook.com ([10.164.203.35]) with mapi id 15.20.0218.011; Sun, 12 Nov 2017 04:41:26 +0000 From: Mike Bishop To: Kazuho Oku , Kari Hurtta CC: Takeshi Yoshino , hybi , "Patrick McManus" , HTTP Working Group Thread-Topic: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt Thread-Index: AQHTW05bYfx7k+xLBU+T/jdvGYckQqMQKgwA Date: Sun, 12 Nov 2017 04:41:25 +0000 Message-ID: References: <20171110061456.1349EB532F@welho-filter2.welho.com> <201711101751.vAAHpqHC031731@shell.siilo.fmi.fi> <201711111045.vABAjCvK027388@shell.siilo.fmi.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:8c74:1a7c:55c6:fd3d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB3471; 6:LD7eqJbcOno/H4a3sJQuNdHAjP/didzNAQRHFm4TGpuxPdt5JSBD06whhJasjBtmxF090Ly/+iOOo6Y0HEW9qRTHgMA5KIWcQqcvPuErgSRwRWMnI3Gm28A7INp05OBiCDY9f2fiFcfGoz6Ah4fAYrpDTMz2+AJgKBOiPZpOO1LqujGjbPOz58M3Uz10kAfmYzFK89VmaHRizCNEZdYkn1VoLfedHtc2JLx2syZR18YmO3wgIfiQeSFbB057iN49hU6/+4aGcUyyt5wArnERRi099tf7sF7iCibV7JivEW8CtDebmv5Qky2EihAr9F2r3K7YZD7PkomWM2qw2GTMOnpe7ThXL/vxbADjMLYcwJM=; 5:R0jX0eVytRKGl8N4YWuvH0WvcrqKH+QW2bwcgTEdx0zi75g0DMc2WgrLHGDIRCSAXycDVFihb4wTOjdjkU+38BXadEaWILFBewtPkHl/nfzQxzQ4YoJ5Wz8iMCKNKokmbyzEYJ3ndYvClRbDCTc3oloPZH31ZZ9Q7N8SXX3BZUs=; 24:g4WzzaYGfse3F7LLjHne7u4q+psHH6VYfW6im3jJwNzqavmRADUu9oK0EdWYB2tFXDngqR/m4ErioPzuNL5Y5h/iy7VFjLFyfkbDSBD5vs8=; 7:AKv4ka6C4A5PKtcFXmPK5In+RlogCV8+moTxWUcVXP2eoyN0/5LqQiasPCiH6ExthnuJrkDtsceDONzJBp/xQ7krgQ8p+0/Oa3oVTllcjJBWXSmMZwrZG967bKoM2orlZi1m59o5bnjEsj8dVPH3z/Ekx3NSvW8AWdTFJQ/hhVNr12A8d3l5SLaTXIk+i7zINf+uz2A/jevUe7i69HVDKj39LcQj/ruTRlfHKKuG8lqH6mRaC+zdhF5toDyejFxz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4236ab47-2b22-40b3-e895-08d52987a24a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603258); SRVR:MWHPR08MB3471; x-ms-traffictypediagnostic: MWHPR08MB3471: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231022)(920507027)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(2016111802025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB3471; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB3471; x-forefront-prvs: 0489CFBAC9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39830400002)(346002)(13464003)(377424004)(43544003)(189002)(199003)(54906003)(53936002)(39060400002)(102836003)(25786009)(74316002)(6116002)(4326008)(2900100001)(33656002)(106356001)(316002)(230783001)(229853002)(345774005)(93886005)(76176999)(15650500001)(105586002)(2950100002)(99286004)(50986999)(54356999)(101416001)(53546010)(6436002)(6246003)(8676002)(5660300001)(81166006)(6506006)(966005)(55016002)(81156014)(34040400001)(97736004)(4001150100001)(478600001)(7696004)(7736002)(6306002)(86362001)(9686003)(305945005)(68736007)(8936002)(3660700001)(77096006)(189998001)(14454004)(110136005)(74482002)(3280700002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB3471; H:MWHPR08MB3472.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 4236ab47-2b22-40b3-e895-08d52987a24a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2017 04:41:26.0278 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB3471 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 04:41:31 -0000 SXQgdGVsbHMgdGhlIGNsaWVudCB3aGF0IHByb3RvY29sKHMpIGl0IG11c3QgdXBncmFkZSB0byBp ZiB0aGUgcmVxdWVzdCBpcyB0byBzdWNjZWVkOyBpdCBkb2Vzbid0IHNlZW0gYW4gdW5yZWFzb25h YmxlIHJlc3BvbnNlIGlmIHRoZSBjbGllbnQgZGlkbid0IG9mZmVyIHRoZSBwcm90b2NvbChzKSB0 aGUgc2VydmVyIHdhcyBleHBlY3RpbmcuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBLYXp1aG8gT2t1IFttYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbV0gDQpTZW50OiBTdW5k YXksIE5vdmVtYmVyIDEyLCAyMDE3IDg6MzIgQU0NClRvOiBLYXJpIEh1cnR0YSA8aHVydHRhLWll dGZAZWxtbWUtbWFpbGVyLm9yZz4NCkNjOiBUYWtlc2hpIFlvc2hpbm8gPHR5b3NoaW5vQGdvb2ds ZS5jb20+OyBoeWJpIDxoeWJpQGlldGYub3JnPjsgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Bt b3ppbGxhLmNvbT47IEhUVFAgV29ya2luZyBHcm91cCA8aWV0Zi1odHRwLXdnQHczLm9yZz4NClN1 YmplY3Q6IFJlOiBbaHliaV0gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LW1jbWFudXMtaHR0cGJpcy1oMi13ZWJzb2NrZXRzLTAxLnR4dA0KDQpIaSwNCg0KMjAxNy0xMS0x MSAxODo0NSBHTVQrMDg6MDAgS2FyaSBIdXJ0dGEgPGh1cnR0YS1pZXRmQGVsbW1lLW1haWxlci5v cmc+Og0KPiBLYXp1aG8gT2t1IDxrYXp1aG9va3VAZ21haWwuY29tPjogKFNhdCBOb3YgMTEgMDk6 NDY6NTggMjAxNykgPC4uLj4NCj4+ID4gV2UgY291bGQgZGVzaWduIGVycm9yIGNvZGUsIGZhbGxi YWNrLCBldGMuIGZvciB0aGlzIGtpbmQgb2YgY2FzZXMgDQo+PiA+IGlmIGl0IHR1cm5zIG91dCB3 ZSByZWFsbHkgbmVlZCB0byB0YWtlIGNhcmUgb2YuIEZvciB0aGUgaW5pdGlhbCANCj4+ID4gaW1w bGVtZW50YXRpb24sIG1heWJlIHdlIGNvdWxkIGp1c3QgbGV0IGJyb3dzZXJzIGdpdmUgdXAgd2hl biBhIA0KPj4gPiBjb25uZWN0aW9uIGF0dGVtcHQgZmFpbHMgb24gYSBjb25uZWN0aW9uIHdpdGgg RU5BQkxFX1VQR1JBREUgKG9yIEVOQUJMRV9DT05ORUNUX1BST1RPQ09MKSBhbm5vdW5jZWQuDQo+ Pg0KPj4gSSBhZ3JlZS4NCj4+DQo+PiBXaGlsZSBJIGFncmVlIHRoYXQgaGF2aW5nIGEgc3RhdHVz IGNvZGUgdGhhdCBpbmRpY2F0ZXMgZmFpbHVyZSB0byANCj4+IHVwZ3JhZGUgdGhlIGNvbm5lY3Rp b24gImVuZC10by1lbmQiIG1pZ2h0IGJlIGEgbmljZSBpZGVhLCBJIHdvdWxkIA0KPj4gYWxzbyBh cmd1ZSB0aGF0IHRoZSBuZWNlc3NpdHkgaXMgbm90IHNwZWNpZmljIHRvIEhUVFAvMi4NCj4+DQo+ PiBXZSBjb3VsZCBoYXZlIGhhZCBhIGNvbm5lY3Rpb24tY2Fubm90LWJlLXVwZ3JhZGVkIHN0YXR1 cyBjb2RlIGZvciANCj4+IEhUVFAvMS4xLiBCdXQgaW4gcmVhbGl0eSwgd2UgZG8gbm90IGhhdmUg c3VjaCBhIHN0YXR1cyBjb2RlLCBhbmQgDQo+PiBub2JvZHkgaGFzIGFyZ3VlIGZvciBoYXZpbmcg dGhhdCAoYXMgSSBrbm93IG9mKS4NCj4NCj4gVGhlcmUgaXMgKHNvcnQgb2YpDQo+DQo+IDQyNiBV cGdyYWRlIFJlcXVpcmVkDQo+DQo+DQo+IG5vcm1hbGx5LCBpZiBVcGdyYWRlIGNhbiBub3QgZG9u ZSwgaHR0cCByZXF1ZXN0IGlzIHByb2Nlc3NlZCB3aXRob3V0IA0KPiBwcm90b2NvbCBjaGFuZ2Uu ICBUaGlzIHN0YXR1cyBjb2RlIGFsbG93cyByZWZ1c2luZyBvZiBwcm9jZXNzaW5nLg0KPg0KPiA0 MjYgVXBncmFkZSBSZXF1aXJlZA0KPg0KPiBpcyBkZWZpbmVkIG9uDQo+DQo+IFJGQyAyODE3OiBV cGdyYWRpbmcgdG8gVExTIFdpdGhpbiBIVFRQLzEuMQ0KPiBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjMjgxNw0KPg0KPg0KPiBZZXMsIHRoYXQgc3RhdHVzIGNvZGUgaXMgZm9yIHNvbWV3 aGF0IGRpZmZlcmVudCBwdXJwb3NlLg0KDQpUaGFuayB5b3UgZm9yIHBvaW50aW5nIHRoYXQgb3V0 Lg0KDQpNeSB2aWV3IGlzIHRoYXQgNDI2IGlzIGEgc3RhdHVzIGNvZGUgdGhhdCBpbnN0cnVjdHMg YSBjbGllbnQgdG8gdXBncmFkZSB0aGUgY29ubmVjdGlvbiAob3IgYSBzdHJlYW0pLg0KDQpJIGRv IG5vdCB0aGluayB0aGF0IGl0IHdvdWxkIGJlIHRoZSBzdGF0dXMgY29kZSB0aGF0IHdlIGNhbiB1 c2UgZm9yIHRlbGxpbmcgdGhlIGNsaWVudCB0aGF0IHRoZSBzdHJlYW0gY291bGQgbm90IGJlIHVw Z3JhZGVkIGV2ZW4gdGhvdWdoIHRoZSBjbGllbnQgcmVxdWVzdGVkIHRoZSB1cGdyYWRlLg0KDQo+ DQo+PiBDb25zaWRlcmluZyB0aGUgZmFjdCwgSSB3b3VsZCBhbnRpY2lwYXRlIHRoYXQgd2Ugd2ls bCBiZSBmaW5lIHdpdGhvdXQgDQo+PiBhZGRpbmcgYSBuZXcgc3RhdHVzIGNvZGUgdG8gaW5kaWNh dGUgc3VjaCBmYWlsdXJlLg0KPj4NCj4+IC0tDQo+PiBLYXp1aG8gT2t1DQo+DQo+IC8gS2FyaSBI dXJ0dGENCj4NCg0KDQoNCi0tDQpLYXp1aG8gT2t1DQoNCg== From nobody Sun Nov 12 11:00:15 2017 Return-Path: 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 AAD9B124C27 for ; Sun, 12 Nov 2017 11:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001] autolearn=ham autolearn_force=no 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 MQXmJ1b5GtaI for ; Sun, 12 Nov 2017 11:00:11 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 995A01243FE for ; Sun, 12 Nov 2017 11:00:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D640C97B56; Sun, 12 Nov 2017 21:00:07 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id w3iCtaijmgGu; Sun, 12 Nov 2017 21:00:07 +0200 (EET) Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPS id E94C22313; Sun, 12 Nov 2017 20:59:58 +0200 (EET) To: Kazuho Oku Date: Sun, 12 Nov 2017 21:00:07 +0200 (EET) Sender: hurtta@hurtta09lk.keh.iki.fi From: Kari Hurtta CC: Kari Hurtta , Patrick McManus , Andy Green , John Fallows , hybi , HTTP Working Group X-Mailer: ELM [version ME+ 2.5 PLalpha46+] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20171112190007.D640C97B56@welho-filter4.welho.com> Archived-At: Subject: [hybi] :upgrade? reserve proxies (HTTP/2 to HTTP/1.1) | Re: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 19:00:14 -0000 https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0209.html > * 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 I was difficulties to interpret this "use attributes of :upgrade: header to specify additional headers required for the upgrade" > 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 > If attributes of :upgrade: header to specify additional headers required for the upgrade, then this look like :upgrade: websocket; sec-websocket-key; sec-websocket-protocol; sec-websocket-version But you not really mean that. > Response: > :status: 101 > :upgrade: websocket > sec-websocket-accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= > sec-websocket-protocol: chat > > > 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: > > > Response: > :status: 101 > :upgrade: h2c > > > 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. That ":upgrade: pseudo header is used to convey the connection headers required for upgrade" tells what you mean, but that is different than additional headers required for the upgrade. Yes. It make sense that :protocol or :upgrade is specified that way that reverse proxy can do HTTP/2 ⇒ HTTP/1.1 Upgrade: conversion without knowing details of upgraded protocol. I think that this is useful property. HTTP/2 is soemtimse terminated on reverse proxy and forwarded as HTTP/1.1 to back end servers. / Kari Hurtta From nobody Mon Nov 13 09:49:17 2017 Return-Path: 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 5CCF812946E for ; Mon, 13 Nov 2017 09:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 1Smwoy6RF2UB for ; Mon, 13 Nov 2017 09:49:13 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493CF128768 for ; Mon, 13 Nov 2017 09:49:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 59FBC5DEB0; Mon, 13 Nov 2017 19:49:10 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id jGK13MikIY7g; Mon, 13 Nov 2017 19:49:09 +0200 (EET) Received: from hurtta09lk.keh.iki.fi (89-27-39-95.bb.dnainternet.fi [89.27.39.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPS id 8671E27F; Mon, 13 Nov 2017 19:49:04 +0200 (EET) In-Reply-To: References: To: Patrick McManus Date: Mon, 13 Nov 2017 19:49:14 +0200 (EET) Sender: hurtta@hurtta09lk.keh.iki.fi From: Kari Hurtta CC: HTTP working group mailing list , Kari Hurtta , hybi X-Mailer: ELM [version ME+ 2.5 PLalpha46+] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20171113174910.59FBC5DEB0@welho-filter3.welho.com> Archived-At: Subject: [hybi] draft-mcmanus-httpbis-h2-websockets-02.txt, 5. Using Extended CONNECT To Bootstrap The WebSocket Protocol, status code X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 17:49:15 -0000 5. Using Extended CONNECT To Bootstrap The WebSocket Protocol https://tools.ietf.org/html/draft-mcmanus-httpbis-h2-websockets-02#section-5 This should mention that :status = 200 replaces status code 101 used on RFC 6455, section 1.3. 1.3. Opening Handshake https://tools.ietf.org/html/rfc6455#section-1.3 " The handshake from the server is much simpler than the client " handshake. The first line is an HTTP Status-Line, with the status " code 101: " " HTTP/1.1 101 Switching Protocols " " Any status code other than 101 indicates that the WebSocket handshake " has not completed and that the semantics of HTTP still apply. The " headers follow the status code. 8.1.1. Upgrading from HTTP/2 https://tools.ietf.org/html/rfc7540#section-8.3 " HTTP/2 removes support for the 101 (Switching Protocols) " informational status code ([RFC7231], Section 6.2.2). " " The semantics of 101 (Switching Protocols) aren't applicable to a " multiplexed protocol. Alternative protocols are able to use the same " mechanisms that HTTP/2 uses to negotiate their use (see Section 3). / Kari Hurtta From nobody Sat Nov 18 08:09:22 2017 Return-Path: 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 DF22E12762F for ; Sat, 11 Nov 2017 23:47:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 rQCkAYGZv2eW for ; Sat, 11 Nov 2017 23:47:14 -0800 (PST) Received: from smtpVgate.fmi.fi (smtpvgate.fmi.fi [193.166.223.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D03DC12751F for ; Sat, 11 Nov 2017 23:47:13 -0800 (PST) Received: from souk.fmi.fi (souk.fmi.fi [193.166.211.113]) (envelope-from hurtta@siilo.fmi.fi) by smtpVgate.fmi.fi (8.13.8/8.13.8/smtpgate-20161014/smtpVgate) with ESMTP id vAC7l7P7002782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 12 Nov 2017 09:47:07 +0200 Received: from shell.siilo.fmi.fi by souk.fmi.fi with ESMTP id vAC7l79S007660 for ; Sun, 12 Nov 2017 09:47:07 +0200 Received: from shell.siilo.fmi.fi ([127.0.0.1]) by shell.siilo.fmi.fi with ESMTP id vAC7l6U9019211 for ; Sun, 12 Nov 2017 09:47:06 +0200 Received: by shell.siilo.fmi.fi id vAC7l67g019210 for hybi@ietf.org; Sun, 12 Nov 2017 09:47:06 +0200 Message-Id: <201711120747.vAC7l67g019210@shell.siilo.fmi.fi> Sender: hurtta@siilo.fmi.fi In-Reply-To: References: <20171111210725.4A2D553719@welho-filter1.welho.com> To: Kazuho Oku Date: Sun, 12 Nov 2017 09:44:20 +0200 (EET) From: Kari Hurtta cc: Patrick McManus , Mike Bishop , Kari Hurtta , HTTP Working Group , Cory Benfield X-Mailer: ELM [version ME+ 2.5 PLalpha46] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="UTF-8" X-Filter: smtpVgate.fmi.fi: 3 received headers rewritten with id 20171112/00983/01 X-Filter: smtpVgate.fmi.fi: ID 0983/01, 1 parts scanned for known viruses X-Filter: souk.fmi.fi: ID 126317/01, 1 parts scanned for known viruses X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (smtpVgate.fmi.fi [193.166.223.36]); Sun, 12 Nov 2017 09:47:07 +0200 (EET) Archived-At: X-Mailman-Approved-At: Sat, 18 Nov 2017 08:09:20 -0800 Subject: [hybi] Proxies | Re: Extending HTTP/2 | Re: New Version Notification for draft-mcmanus-httpbis-h2-websockets-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Nov 2017 07:47:17 -0000 Kazuho Oku : (Sun Nov 12 02:27:25 2017) > I now do not think that "upgrade" needs to be a pseudo header. > > The reason I proposed having :upgrade: pseudo header was due to my > understanding that HTTP/2 prohibited hop-by-hop headers, and that we ( on here I aggreed with Patrick McManus : "a colon header is a transport specific (i.e. hop to hop) header. … it changes the dynamics of the transaction into a fully bidirectional channel and that's transport specific." https://lists.w3.org/Archives/Public/ietf-http-wg/2017OctDec/0241.html ) > are trying to revive the "upgrade" hop-by-hop header of HTTP/1 by > trying to implement Websocket (or a generic upgrade) on HTTP/2. It > seemed to me that defining it as an extraordinary header (i.e. pseudo > header) seemed to make sense. > > But reconsidering this, I now believe that what we are trying to > define is an end-to-end upgrade of a stream. In H2WS, we use a > SETTINGS parameter for hop-by-hop negotiation. 1) forward proxyes (which are configured to browser) still use regular CONNECT -method. https://github.com/mcmanus/draft-h2ws/blob/master/draft-mcmanus-httpbis-h2-websockets-02.txt " This document does not change how WebSockets interacts with HTTP " proxies. If a client wishing to speak WebSockets connects via HTTP/2 " to a HTTP proxy it should continue to use a traditional (i.e. not " with a :protocol pseudo-header) CONNECT to tunnel through that proxy " to the WebSocket server via HTTP. 4.1. Client Requirements https://tools.ietf.org/html/rfc6455#section-4.1 " 3. _Proxy Usage_: If the client is configured to use a proxy when " using the WebSocket Protocol to connect to host /host/ and port " /port/, then the client SHOULD connect to that proxy and ask it " to open a TCP connection to the host given by /host/ and the port " given by /port/. " " EXAMPLE: For example, if the client uses an HTTP proxy for all " traffic, then if it was to try to connect to port 80 on server " example.com, it might send the following lines to the proxy " server: " " CONNECT example.com:80 HTTP/1.1 " Host: example.com 2) It is reverse proxies which see Upgrade: on HTTP/1.1 and :method = CONNECT :protocol = websocket on HTTP/2. These reverse proxies listen IP address which resolves from name given on Host -header or :authority pseudo header. I often also refer situation where reverse proxy does TLS offloading — TLS is terminated on reverse proxy. ( Often reverse proxy ↔ backend server connection is not encrypted — sometimes it is re-encrypted — there is another TLS connection to backend server. ) / Kari Hurtta