Re: WebSocket2

[Takeshi Yoshino <[e-mail]>]

Hi Kari,

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

On Wed, Oct 5, 2016 at 12:20 AM, Kari Hurtta <[e-mail]>
wrote:

<snip>


> I contemplated SETTINGS as:
>
> ∙ SETTINGS frame with SETTINGS_WEBSOCKET_CAPABLE = 1
>   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").
>
>   ∘ SETTINGS_WEBSOCKET_CAPABLE = 1 does
>     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.

<snip>


> > :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.
> SMTP.
> > 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,".

<snip>