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

Takeshi Yoshino <> Fri, 10 November 2017 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5872A12ECC6 for <>; Fri, 10 Nov 2017 10:10:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6bWhFm-EOuDr for <>; Fri, 10 Nov 2017 10:10:32 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AC24212ECC4 for <>; Fri, 10 Nov 2017 10:10:32 -0800 (PST)
Received: by 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;; 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;; 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 with SMTP id c27mr2094006qtd.282.1510337431630; Fri, 10 Nov 2017 10:10:31 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Fri, 10 Nov 2017 10:10:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
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-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

On Sat, Nov 11, 2017 at 2:51 AM, Kari Hurtta <>

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

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.