Re: WebSocket2

[Kari Hurtta <[e-mail]>]

Takeshi Yoshino <[e-mail]>: (Tue Oct  4 14:12:25 2016)
> Hi Van, Kari,
> 
> On Tue, Oct 4, 2016 at 1:39 AM, Van Catha <[e-mail]> wrote:
> 
> <snip>
> 
> 
> > Kari Hurtta
> >
> > > Well, I think the following would work and avoid SETTINGS:
> > >
> >
> 
> Yutaka's proposal required the SETTINGS_WEBSOCKET_CAPABLE SETTINGS
> parameter because we planned to use special framing (use of HTTP2 framing
> level features not used for HTTP1.1/h2 layering). We wanted allow endpoints
> to make sure that the h2 intermediaries between them are able to forward
> WS/HTTP2's special framing correctly.
> 
> So, for the current proposal by Van where only the DATA frame is used as
> well as HTTP1.1/h2 layering, it's unnecessary.

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

  (※)

∙ Promise of HTTP/1 client (⇒ HTTP/2 server)
  is implied with ":scheme" = "wss" or "ws". 

> > > -> :method ws2
> > > -> :scheme wss
> > > -> :authority foo.example
> > > -> :path /bar
> > > -> <optional extra parameters, e.g. compression support>
> > > <- :status 200
> > > <- sec-ws2-ack 1
> > > <- <optional negotiated extras>
> >
> >
> :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).

/ Kari Hurtta



(※)  Yes, on my network picture there is 
     many HTTP/2 servers and clients:

    +---------------------------+
    | Web browser or other      |
    | WebSockect client         |
    +---------------------------+   [ HTTP/2 client ]
                 ⇓
                 ⇓
    +---------------------------+   [ HTTP/2 server ]
    | forward proxy configure   |     ( client uses CONNECT
    | on web blowser            |       tunnel if encypted scheme )
    +---------------------------+  [ HTTP/2 client ]
                 ⇓
                 ⇓
    +---------------------------+  [ HTTP/2 client ]
    | reverse proxy for         |   ( may include TLS offloading,
    | :authority                |     if encryption is used )
    +---------------------------+  [ HTTP/2 client ] 
                 ⇓
                 ⇓
    +---------------------------+  [ HTTP/2 server ]
    | origin server             |
    |                           |
    +---------------------------+


SETTINGS frame is for one hop between
HTTP/2 server and HTTP/2 client.