Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
Takeshi Yoshino <tyoshino@google.com> Fri, 10 November 2017 16:56 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D78F128A32 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 Nov 2017 08:56:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=unavailable 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 1wNmyg7eLUz3 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 10 Nov 2017 08:56:57 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B69B6129400 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 10 Nov 2017 08:56:56 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1eDCXG-0003XI-8W for ietf-http-wg-dist@listhub.w3.org; Fri, 10 Nov 2017 16:52:06 +0000
Resent-Date: Fri, 10 Nov 2017 16:52:06 +0000
Resent-Message-Id: <E1eDCXG-0003XI-8W@frink.w3.org>
Received: from mimas.w3.org ([128.30.52.79]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <tyoshino@google.com>) id 1eDCX9-0003Rt-Ll for ietf-http-wg@listhub.w3.org; Fri, 10 Nov 2017 16:51:59 +0000
Received: from mail-qt0-f181.google.com ([209.85.216.181]) by mimas.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <tyoshino@google.com>) id 1eDCWx-00062s-O3 for ietf-http-wg@w3.org; Fri, 10 Nov 2017 16:51:59 +0000
Received: by mail-qt0-f181.google.com with SMTP id d43so1870068qte.13 for <ietf-http-wg@w3.org>; 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=VRqRrhXRFxrvpN7ixzoY1K+JDwGP3Gl1x3ZJOI7hRa5piUh4xroa50KbEHMh3afsw5 4x4pVY4cgZnoompJefvLG+DzvzpwyMjZxbnMZ5soQg6LuakjiENkarQqQJ6CMLk0UA3Z EIhvQfb5tGXI6+Hn/HG+CuW9TaJfVWyUSmEGabUuPDfAcIttkDkds7xAMi49/lBXbJY5 TrOuqnguIQHtI+ddVQSDSXMQD8E+eFViLbVjTYsg2DETpoq1gP4iD/gz8j1PD6l//tLo gmYl7woNOtIJkzqCoM8q7HUvuYsMzq6b6BAK2PUetGur6mtBx6f30Mnxs/i8fwF4GClK 9jIQ==
X-Gm-Message-State: AJaThX4B/yowruIGjHtIeaOoICjyAwQ/YQNq7TI6DjkrxzMB8Ijg7nX4 1Bhzr4iQCMhpCbCrObTsOuju6R8dGh8+0asNpe3iAg==
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: <CANatvzya831tQdWsjpiwdF537jVqZYCQpi3aFHLdQoGjShcCRw@mail.gmail.com>
References: <CAD3-0rPPGx4k+ksk-QDnNhnescfPHiYSJ-z2AQeMR2=khaO_HQ@mail.gmail.com> <20171110061456.1349EB532F@welho-filter2.welho.com> <CANatvzya831tQdWsjpiwdF537jVqZYCQpi3aFHLdQoGjShcCRw@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Sat, 11 Nov 2017 01:51:05 +0900
Message-ID: <CAH9hSJapY-KxFwMzGp4vmNcZuu5R8gJ+es4Rs1Le8G2CWPLjsQ@mail.gmail.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, hybi <hybi@ietf.org>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="001a11420b0a44784a055da3bb49"
Received-SPF: pass client-ip=209.85.216.181; envelope-from=tyoshino@google.com; helo=mail-qt0-f181.google.com
X-W3C-Hub-Spam-Status: No, score=-6.2
X-W3C-Hub-Spam-Report: AWL=0.515, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: mimas.w3.org 1eDCWx-00062s-O3 332e4339ae1e633943be014c93d3aa4c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt
Archived-At: <http://www.w3.org/mid/CAH9hSJapY-KxFwMzGp4vmNcZuu5R8gJ+es4Rs1Le8G2CWPLjsQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/34748
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
On Fri, Nov 10, 2017 at 4:05 PM, Kazuho Oku <kazuhooku@gmail.com> wrote: > 2017-11-10 15:14 GMT+09:00 Kari Hurtta <hurtta-ietf@elmme-mailer.org>: > > 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 <https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01> 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.
- Fwd: New Version Notification for draft-mcmanus-h… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… John Fallows
- Re: [hybi] Fwd: New Version Notification for draf… Martin Thomson
- Re: [hybi] Fwd: New Version Notification for draf… Andy Green
- Re: [hybi] New Version Notification for draft-mcm… Mark Nottingham
- Re: [hybi] New Version Notification for draft-mcm… Mark Nottingham
- Re: [hybi] New Version Notification for draft-mcm… Martin Thomson
- Re: [hybi] Fwd: New Version Notification for draf… Amos Jeffries
- Re: [hybi] Fwd: New Version Notification for draf… Andy Green
- Re: [hybi] Fwd: New Version Notification for draf… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… Amos Jeffries
- Re: [hybi] Fwd: New Version Notification for draf… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… John Fallows
- Re: [hybi] Fwd: New Version Notification for draf… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… John Fallows
- Re: [hybi] Fwd: New Version Notification for draf… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… Anne van Kesteren
- Re: New Version Notification for draft-mcmanus-ht… Kazuho Oku
- Re: New Version Notification for draft-mcmanus-ht… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… Patrick McManus
- Re: [hybi] Fwd: New Version Notification for draf… Willy Tarreau
- Re: [hybi] Fwd: New Version Notification for draf… Kazuho Oku
- Re: [hybi] Fwd: New Version Notification for draf… Wenbo Zhu
- Re: [hybi] Fwd: New Version Notification for draf… Kari Hurtta
- Re: [hybi] Fwd: New Version Notification for draf… Kari Hurtta
- Re: [hybi] Fwd: New Version Notification for draf… Andy Green
- Re: [hybi] Fwd: New Version Notification for draf… Kazuho Oku
- Re: [hybi] Fwd: New Version Notification for draf… Takeshi Yoshino
- Re: [hybi] Fwd: New Version Notification for draf… Kari Hurtta
- Re: [hybi] Fwd: New Version Notification for draf… Kari Hurtta
- Re: [hybi] Fwd: New Version Notification for draf… Takeshi Yoshino
- Re: [hybi] Fwd: New Version Notification for draf… Takeshi Yoshino
- Re: [hybi] Fwd: New Version Notification for draf… Amos Jeffries
- Re: [hybi] Fwd: New Version Notification for draf… Kazuho Oku
- proxy & ENABLE_UPGRADE SETTINGS | Re: [hybi] Fwd:… Kari Hurtta
- Re: [hybi] Fwd: New Version Notification for draf… Kari Hurtta
- Re: proxy & ENABLE_UPGRADE SETTINGS | Re: [hybi] … Amos Jeffries
- Re: proxy & ENABLE_UPGRADE SETTINGS | Re: [hybi] … Kari Hurtta
- SETTINGS ENABLE_WEBSOCKET ?? | Re: proxy & ENABLE… Kari Hurtta
- Re: [hybi] Fwd: New Version Notification for draf… Kazuho Oku
- RE: [hybi] Fwd: New Version Notification for draf… Mike Bishop