Re: WebSocket2

Kari hurtta <hurtta-ietf@elmme-mailer.org> Fri, 07 October 2016 16:44 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 4F40812956C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 7 Oct 2016 09:44:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.417
X-Spam-Level:
X-Spam-Status: No, score=-9.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 zoTY96_d6Ecv for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Fri, 7 Oct 2016 09:44:53 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A385128B44 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Fri, 7 Oct 2016 09:44:53 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bsYCf-0005Ot-Oq for ietf-http-wg-dist@listhub.w3.org; Fri, 07 Oct 2016 16:40:57 +0000
Resent-Date: Fri, 07 Oct 2016 16:40:57 +0000
Resent-Message-Id: <E1bsYCf-0005Ot-Oq@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <khurtta@welho.com>) id 1bsYCb-0005OA-9h for ietf-http-wg@listhub.w3.org; Fri, 07 Oct 2016 16:40:53 +0000
Received: from welho-filter4.welho.com ([83.102.41.26]) by maggie.w3.org with esmtp (Exim 4.80) (envelope-from <khurtta@welho.com>) id 1bsYCZ-0001zT-9H for ietf-http-wg@w3.org; Fri, 07 Oct 2016 16:40:52 +0000
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7E58C163ED; Fri, 7 Oct 2016 19:40:23 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id nBkHuQotto6a; Fri, 7 Oct 2016 19:40:22 +0300 (EEST)
Received: from hurtta09lk.keh.iki.fi (89-27-35-245.bb.dnainternet.fi [89.27.35.245]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPS id A2F5821C; Fri, 7 Oct 2016 19:40:22 +0300 (EEST)
In-Reply-To: <CAG-EYCiCkC2XWuhbOtwKusW28=p-sYLArDR6MfN1Zc41+9f2-A@mail.gmail.com>
References: <CAG-EYChPJpAzoEuNwY3cNz503d0FRbNnDx_9AsNsZyfb5nmN0g@mail.gmail.com> <20161002080030.5F328160CC@welho-filter4.welho.com> <20161002101548.GA9450@LK-Perkele-V2.elisa-laajakaista.fi> <201610021110.u92BAWpi019029@shell.siilo.fmi.fi> <20161002124346.GB9450@LK-Perkele-V2.elisa-laajakaista.fi> <201610021340.u92DeBBL029907@shell.siilo.fmi.fi> <20161002171905.GA10108@LK-Perkele-V2.elisa-laajakaista.fi> <201610030440.u934e3kL031002@shell.siilo.fmi.fi> <CAG-EYCgEs1oSdLeLVwd12ECaL=+3pzytuy89xFWvvKCEY8fi4g@mail.gmail.com> <CAH9hSJaMsKaoTK+kr2X_GP_T7=jcDQtFLSusYrV+nDWCadcyxg@mail.gmail.com> <201610041520.u94FK6vV008976@shell.siilo.fmi.fi> <CAH9hSJY40AnYE1JTuc1aYFzRtaT-+PwX8M7YeVj2cbosCfD0TQ@mail.gmail.com> <CAG-EYCiCkC2XWuhbOtwKusW28=p-sYLArDR6MfN1Zc41+9f2-A@mail.gmail.com>
To: Van Catha <vans554@gmail.com>
Date: Fri, 7 Oct 2016 19:40:22 +0300 (EEST)
Sender: hurtta@hurtta09lk.keh.iki.fi
From: Kari hurtta <hurtta-ietf@elmme-mailer.org>
CC: Takeshi Yoshino <tyoshino@google.com>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
X-Mailer: ELM [version ME+ 2.5 PLalpha42]
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20161007164023.7E58C163ED@welho-filter4.welho.com>
Received-SPF: none client-ip=83.102.41.26; envelope-from=khurtta@welho.com; helo=welho-filter4.welho.com
X-W3C-Hub-Spam-Status: No, score=-6.5
X-W3C-Hub-Spam-Report: AWL=-0.413, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.676, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bsYCZ-0001zT-9H 4cba81730433bd86e508abaab83d7b75
X-Original-To: ietf-http-wg@w3.org
Subject: Re: WebSocket2
Archived-At: <http://www.w3.org/mid/20161007164023.7E58C163ED@welho-filter4.welho.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/32521
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>

> Kari and other participants, which way do you think would be better:
> 
> RFC of Websocket2  updates RFC 7540 (HTTP/2)
> OR
> RFC of Websocket2 registers new method.
> 
> Using it this way you proposed would it require adding
> SETTINGS_WEBSOCKET_CAPABLE
> as well?
> 
> I think the SETTINGS_WEBSOCKET_CAPABLE can be included in the RFC and if
> a middle box does not implement support for it, as long as it forwards
> everything correctly
> AND the response contains the sec-ws2-error header, there should not be
> problems?

• Assuming
  
  ":scheme"    = "wss"  (or  "ws"  on forward proxy scenario )
  ":authority" = "foo.example"
  ":method"    = "CONNECT"
  ":path"      = "/bar"

  ( This may need: RFC of Websocket2  updates RFC 7540 (HTTP/2) )

  ‣ benefit

    ∘ If http/2 component does not support Websocket2, this produces
      http/2 error code PROTOCOL_ERROR  (because ":scheme" and
      ":path" are not allowed).

    ∘ ":method" = "CONNECT" have already semantic
      which implies that DATA frames are not
      collected for request or response body
      and DATA frame traffic is bidirectional.

  ‣ disadvantage

    ∘ There is danger that PROTOCOL_ERROR error 
      is sent with GOAWAY. This means closing
      of connection (expensive).

      If PROTOCOL_ERROR error is sent with
      RST_STREAM, then this is good.

      ∷  SETTINGS_WEBSOCKET_CAPABLE  from http/2
	 server to http/2 client avoids
	 possible PROTOCOL_ERROR

    ∘ ":scheme" and ":path" may be ignored. 
      { Ignoring violates MUST clause on RFC 7540. }
      ( Forward proxy may try open tcp connection
        to ":authority". )

• Assuming

  ":scheme"    = "wss"  (or  "ws"  on forward proxy scenario )
  ":authority" = "foo.example"
  ":method"    = "WS2"
  ":path"      = "/bar"

  ( This may need: RFC of Websocket2 registers new method )

  ‣ benefit

    ∘ if http/2 (or http/1.1 behind reverse proxy) server 
      does not support that method it can give
      http status code 405 (Method Not Allowed)

      Also http status 501 (Not Implemented) is possible.

    ∘ If http/2 reverse proxy does not buffer DATA,
      it may work without Websocket2 support

    ∘ response header (was it sec-ws2-error? or sec-ws2-ack?)
      may indicate that origin server understand
      ":scheme" and ":path".

  ‣ disadvantage

    ∘ If http/2 component does not support Websocket2,
      it may try buffer assumed http request body
      (all request DATA frames) and response body
      (all response DATA frames). Because some 
      responses can be cached, it make sense to buffer
      them all (to some upper limit of data).

    ∘ ":scheme" may be ignored (or dropped when
      converted to HTTP/1.1 request).

      ∷  SETTINGS_WEBSOCKET_CAPABLE  from http/2
         server to http/2 client help quarantee
	 that DATA frames are not buffered
         excessively and promises that
         ":scheme" is not ignored.

    ∘ If response header (was it sec-ws2-error? or 
      sec-ws2-ack?) is not received, 
      http/2 client may need RST_STREAM 
      opened stream.

If middle box does not support Websocket2,
then it can be assumed that it does not
send SETTINGS_WEBSOCKET_CAPABLE to http/2
client.

It may be possible to send

  ":scheme"    = "wss"  (or  "ws"  on forward proxy scenario )
  ":authority" = "foo.example"
  ":method"    = "WS2"
  ":path"      = "/bar"

to http/2 origin server and then look if
SETTINGS_WEBSOCKET_CAPABLE = 1 is set
by http/2 server. If SETTINGS_WEBSOCKET_CAPABLE
is not set (not received via SETTINGS)
then http/2 client may need RST_STREAM 
opened stream.

That RST_STREAM happens when http/2 server
is finished handshake.  May be expensive.

It is also possible that http/2 server
is set SETTINGS_WEBSOCKET_CAPABLE = 1 on
initial SETTINGS frame. 

> Standardized protocol or not is irrelevant.  I was simply considering the
> options
> and what would work.  QUIC uses different negotiation and transport frames
> then HTTP/2
> does (also QUIC does not have HTTP/2 SETTINGS frames). I was proposing
> ideas at
> tackling the problem to make WebSocket2 work across different transport
> layers.

Obviously you then need omit SETTINGS_WEBSOCKET_CAPABLE
when QUIC is used. I do not know if buffering of DATA
frames is concern on here.

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

/ Kari Hurtta