SETTINGS_WEBSOCKET_CAPABLE | Re: WebSocket2

Takeshi Yoshino <tyoshino@google.com>: (Wed Oct  5 08:28:23 2016)
> 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 <hurtta-ietf@elmme-mailer.org>
> 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").

Quote from WiSH ( https://github.com/bidiweb/wish/blob/master/draft-yoshino-wish-00.txt )
gives more backgroud:

|   responses.  Since proxies may buffer response body, communication
|   over WiSH may experience extra latency compared to WebSocket.  When
|   HTTPS is used, response buffering by proxies is less likely an issue.

Even when proxy does not cache ":scheme" or ":method",
it may buffer assumed HTTP request or response body.

Idelly DATA frames for ":scheme" = "wss" and "ws" want to
be sent immediately when underline protocol stack is empty
(TCP window have space, TCP/Sockect write buffers are empty,
 possible TLS write buffers are empty) and HTTP/2 flow
control windows for that sream have space and HTTP/2
priority tree say that that stream is correct for writing.

( same apply for ":method" = "CONNECT" )

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

yet one more possibility:

It is also possible that HTTP/2 server sets SETTINGS_WEBSOCKET_CAPABLE = 1
on initial SETTINGS which is part of server greeting.  This add little
overhead on case where client does not use websockect2. 

Origin server need send that only of there at least one websocket service 
configured.

HTTP/2 server which is HTTP/2 proxy may need set SETTINGS_WEBSOCKET_CAPABLE = 1 
on initial SETTINGS always when it supports ":scheme" = "wss" or "ws".


<removed>


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

On another context Mike Bishop wrte ( 
https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0037.html )

¤ Should we just define SETTINGS_MIXED_SCHEME_PERMITTED and call it a day?

I realize that ":scheme" = "wss" or "ws" sent on same HTTP/2 connection
than what is used for ":scheme" = "https", is also just one case of
for mixed scheme.

I wrote ( https://lists.w3.org/Archives/Public/ietf-http-wg/2016OctDec/0044.html )

| connection apply probably for several origins. TLS connection
| may be terminated by reverse proxy. And different origins
| are served by different processes or servers behind of
| reverse proxy.
| 
| I guess that SETTINGS_MIXED_SCHEME_PERMITTED is too wide.


This may apply also for SETTINGS_WEBSOCKET_CAPABLE. However confusing
between ":scheme" = "http" and "https" is more dangerous than between
:scheme" = "wss" and "https".

/ Kari Hurtta

Received on Wednesday, 5 October 2016 07:03:41 UTC