Re: WebSocket2

Takeshi Yoshino <> Wed, 05 October 2016 05:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA6D5129513 for <>; Tue, 4 Oct 2016 22:33:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.016
X-Spam-Status: No, score=-10.016 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, 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 pvQCLoJPsc7Z for <>; Tue, 4 Oct 2016 22:33:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ED6AA12940E for <>; Tue, 4 Oct 2016 22:33:14 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1brelX-0006QI-U6 for; Wed, 05 Oct 2016 05:29:15 +0000
Resent-Date: Wed, 05 Oct 2016 05:29:15 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brelU-0006PZ-5v for; Wed, 05 Oct 2016 05:29:12 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1brelS-0005gS-IQ for; Wed, 05 Oct 2016 05:29:11 +0000
Received: by with SMTP id 188so87395386iti.1 for <>; Tue, 04 Oct 2016 22:28:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vMdnh5gJp/s0+4ypB79OEzRSnZVsgsMSst7jLL6dcP0=; b=A8CR4heENsqSa7axFVu9MwsBlGHnTbpsuytkw/fnEO75cTYrfzHjM25ti8Z7blBDPL ztCyz2fiokzVsUJmxeGVKfdl2d5wHPmeq8qsXQ/rf1JJFKlYgDYRwOytDOt8KlXT7JqT zi8c1bPvx3ODD+pIkughJwvnaYPyIGMD5lc5Z4bv+j7nzWZcXfJc8/dup93iwc/Ol4wY 86se7JBITULtrh47KjH96nfRYy8yyeDbqODBGHfJZNjIgCF1vKjkVXp114Tk1rafFVmp MuqciV99ozBqmEeUDykofDXac0PSpg/H/XiBmPK+w0soUcdEYdLjWKw/pgmJ36ANHlcO zHqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vMdnh5gJp/s0+4ypB79OEzRSnZVsgsMSst7jLL6dcP0=; b=BOR4JpjJVwPmjEStxnZ4LYg4ZDrH4KH7PWh1E9ihpTdSwMG4BHOrg7ucl5maef2dQd 2kLmmqIDVK45ede+rIr9csibM/u2Hji0gm8RZRezqxw7tn4CRj9AVzKKQWQvFovjQ3DV AzTrhIvAfzKglkM7hqHfM6yO1DxS1xQfhLv97pJuU4TCqlpsIiVn8f41LnaMbZ7Jah4q yTHJ5GyBQ9+CZcSGIDITe9Q7d0EVFdFM8cNTJ3szS8/LojNmFNq70L3k+gSPUbFsvIKI UyjmsSW8TGO/2wm4Vc5b2Hj1BdPY4HH55XAKP73xl97TOUCcH+cNyJVM6UWW/0uyhWgO D/NA==
X-Gm-Message-State: AA6/9RnaLeVSBcDrGFoAxbA1Pszt+szMYzcP7Mywox4qWijvXqW0gj1bW+qtjIZlTesTdNEgmy3mDWIC613azknF
X-Received: by with SMTP id t129mr8270603itd.31.1475645324202; Tue, 04 Oct 2016 22:28:44 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 4 Oct 2016 22:28:23 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
From: Takeshi Yoshino <>
Date: Wed, 5 Oct 2016 14:28:23 +0900
Message-ID: <>
To: Kari Hurtta <>
Cc: Van Catha <>, Ilari Liusvaara <>, HTTP working group mailing list <>
Content-Type: multipart/alternative; boundary=94eb2c0890fa5d663b053e177367
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.7
X-W3C-Hub-Spam-Report: AWL=1.676, 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, RP_MATCHES_RCVD=-2.64, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1brelS-0005gS-IQ 17a8b01515888f67b21564d9c5350208
Subject: Re: WebSocket2
Archived-At: <>
X-Mailing-List: <> archive/latest/32476
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Kari,

I just remembered that you gave some feedback to Yutaka's proposal in 2014.

On Wed, Oct 5, 2016 at 12:20 AM, Kari Hurtta <>


> I contemplated SETTINGS as:
>   from HTTP/2 server ⇒  HTTP/1 client direction
>   ∘ Promises that HTTP/2 server checks ":scheme"
>     (and specially "wss" and "ws")
>   ∘ Acknowledges that DATA frames for
>     ":scheme" = "wss" and "ws" are handled
>     as bidirectional traffic (similar than
>     ":method" = "CONNECT").
>     In other words these DATA drames do
>     NOT form HTTP request body from client
>     and DATA drames do not form
>     HTTP response body from server
>     (on cases ":scheme" = "wss" and "ws").
>     not promise that HTTP/2 server
>     accepts ":scheme" = "wss" or "ws".

Yutaka's proposal tried to represent the same guarantee by using the
combination of the client to server direction SETTINGS and the response
status code.

I chatted with Yutaka offline. He don't remember the background fully, but
we guess we chose to let the client send SETTINGS because we want to start
sending WebSocket handshake before waiting for response from the server to
reduce the initial latency. Such an attempt may result in failure, but
worth doing for some latency sensitive applications.

There're two approaches to realize this:
(a) let the server send SETTINGS and let the client send handshake
speculatively without waiting for the SETTINGS
(b) let the client send SETTINGS and then send handshake speculatively, and
let the server determine the response status code based on whether or not
it has received SETTINGS as specified in Yutaka's I-D.

(a) still gives the client path check result before receiving the WebSocket
handshake response, but it's not good that the server cannot know whether
the path was good or not before accepting the WebSocket handshake.

One more thing to note is that we were investigating whether we could relax
the requirement of the WebSocket API that messages cannot be sent before
receiving handshake response, when h2 is used. The server needs to process
these speculative messages without determining whether the the path was
good for WS/h2 if we adopt (a).

One small benefit of (b) is that there wouldn't be any
SETTINGS_WEBSOCKET_CAPABLE traffic if the client doesn't want to use WS.

Now I think combining (a) and (b) is the best given the concern that the
server may forget to investigate the SETTINGS correctly but still reply to
a WebSocket handshake with non 501 status code.


> > :scheme is needed, yes.
> >
> > Not sure about need for "sec-ws2-ack". For WebSocket/TCP, we employed the
> > Sec-WebSocket-Key/Accept challenge/response in order to prevent the
> > WebSocket protocol from being abused for cross protocol attacks e.g.
> > If all the intermediaries and servers correctly investigate the :scheme
> > header and don't get confused, "sec-ws2-ack" is unnecessary. Regarding
> > ws/h2-RFC6455 bridging, a correctly implemented intermediary facing ws/h2
> > capable node and ws/h2 non-capable node would just perform RFC 6455
> > handshake as Kari suggested. So, no problem.
> Ilari Liusvaara suggested sec-ws2-ack for check that
> ":scheme" is not ignored (if I remember correctly).

Yeah. I understood so and therefore I said "If all the intermediaries and
servers correctly investigate the :scheme header and don't get confused,".