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

Kazuho Oku <> Mon, 30 October 2017 05:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B52C413F7D9 for <>; Sun, 29 Oct 2017 22:10:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PIsVGW7Mbbfq for <>; Sun, 29 Oct 2017 22:10:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9A63813F546 for <>; Sun, 29 Oct 2017 22:10:15 -0700 (PDT)
Received: by with SMTP id r25so10551356pgn.4 for <>; Sun, 29 Oct 2017 22:10:15 -0700 (PDT)
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=mh7MWpjhcU9rM74JriRh1gPBNnm2UL4D2Cxq8jk9K3U=; b=MGT3in3J/NsPsg1zNbaCVgWdckNAPqbkvwWxIvJpJ7AyL62Hsi5L/Rim8GGuNJfcN3 AX3zsSP+XnUp0lGbia5zxEZP22EdnA6AN+MXg7+nzHBiDRMHUslXLmBtxoZV4oXL0feC 19LbhCOSDwCOtPM6+N7gq19xneDtRHSwUSMX/cradd8GzoT73p8qiXHDb42/0bODgMyU Qn2OevdJ4zD64HQ4HT/7y6t2be4Nsuygho0gtZqinOBeIl1DWX+5QJOEKcMHBTB3wAUW IabykqAQM6tGf510wAMZleO3VwdUrrTCaxfzdaELr3pAQWTKrZjMnFJjvwOqlupL84A/ aXhg==
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=mh7MWpjhcU9rM74JriRh1gPBNnm2UL4D2Cxq8jk9K3U=; b=qvNcOAr0cdjQmLVapLoCfOqGTC1f4Zg/j1ZlolrQT3x5wOGK9SxqtYvvmiXA0KGYcH XeWcvGFah/BEHtgOpVG0tCvs0NJaeDD418EQMWCjNe7HPxQzo6P7lUCzBPmujCmVyIm4 ssH8kA6RGDzCC1mxIBLp7uc/5AzkFK0LByFkJWIETQSbNdyxvBFqS4tMmxMywGnMddY0 ZXwmLJ3eRrS4E8WNtcgSnEQ4Y4SjIpTsJ4GvU/8iLqaZeHxShmPrd3QSuwG9lTygZeei ed+KX5RsffHOgzrL7XlSpVR7X0MsXG1pOGMktx+KGIyI+8mjegGArwru8oZq5ksGZrrt YqFA==
X-Gm-Message-State: AMCzsaULVQsODkOA2doKAC9oRXroUDzqcFHTB6UGhQe5F4dxvitAwqCR aYO6klrBWktKjcfYUIV4LaY/NlIPU7B+rJSR5f8=
X-Google-Smtp-Source: ABhQp+SwyIFx5U4w6YOwhWeazYb9qroc1wsRqaQo+bSWNIYwBUMhZ+OUDoFly6dKk1x4occ6MFkcAGakvYrtjrpBhy8=
X-Received: by with SMTP id q14mr6291292pll.39.1509340215103; Sun, 29 Oct 2017 22:10:15 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Sun, 29 Oct 2017 22:10:14 -0700 (PDT)
In-Reply-To: <>
References: <> <>
From: Kazuho Oku <>
Date: Mon, 30 Oct 2017 14:10:14 +0900
Message-ID: <>
To: Patrick McManus <>
Cc: hybi <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [hybi] 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: Mon, 30 Oct 2017 05:10:18 -0000


Thank you for working on the draft. I am happy to see WebSockets
coming to HTTP/2, and I like that the proposal tries to make changes
caused by the transition minimal.

The biggest issue I wonder if we can continue using HTTP/1 headers for
WebSocket parameter negotiation (e.g., Sec-WebSocket-Version,
Sec-WebSocket-Protocol), instead of sending them in DATA frames.

The reason I ask this is because unless we keep them as headers, it
would become impossible to implement a ws-on-h2 to ws-on-h1 proxy
without dealing with the details of the WebSocket protocol.

In HTTP/1, it has been possible to implement a HTTP proxy that
supports WebSockets, without the knowledge of sub-protocol
negotiation. This is because all the parameters were negotiated
through the use of the HTTP headers, and a proxy could simply forward
them as-is. All the thing that a proxy has been required to do is to
look at the Upgrade header and the status code, and start running a
bi-directional tunnel once the upstream server sends a 101 response.

With the -01 proposal, the same feature is retained only when a proxy
forwards from ws-on-h2 client to a ws-on-h2 server. In the case of
ws-on-h2 client connecting to ws-on-h1 server (or ws-on-h1 client
connecting to ws-on-h2 server), the proxy needs to convert
WebSocket-specific values sent in DATA frame to a HTTP header (or

I wonder if this is a necessary complication. If not, I would prefer
to continue sending all the headers necessary for WebSocket
negotiation in HTTP/2 as well.

2017-10-27 2:32 GMT+09:00 Patrick McManus <>:
> This is an updated based on the direction discussed.. I'm kind of on the
> fence about whether its better. Its nice there is no h1 in there.
> ---------- Forwarded message ----------
> From: <>
> Date: Thu, Oct 26, 2017 at 1:30 PM
> Subject: New Version Notification for
> draft-mcmanus-httpbis-h2-websockets-01.txt
> To: Patrick McManus <>
> A new version of I-D, draft-mcmanus-httpbis-h2-websockets-01.txt
> has been successfully submitted by Patrick McManus and posted to the
> IETF repository.
> Name:           draft-mcmanus-httpbis-h2-websockets
> Revision:       01
> Title:          Bootstrapping WebSockets with HTTP/2
> Document date:  2017-10-26
> Group:          Individual Submission
> Pages:          9
> URL:
> Status:
> Htmlized:
> Htmlized:
> Diff:
> Abstract:
>    This document defines a mechanism for running the WebSocket Protocol
>    [RFC6455] over a single stream of an HTTP/2 connection.
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at
> The IETF Secretariat

Kazuho Oku