Re: SETTINGS_WEBSOCKET_CAPABLE | Re: WebSocket2

[Kari Hurtta <[e-mail]>]

Takeshi Yoshino <[e-mail]>: (Thu Oct 13 10:20:57 2016)
> > 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.
> >
> 
> I think you meant the SETTINGS sent following the connection preface
> (following the Finished message of TLS from the server).

Yes, that SETTINGS which is connection preface.

3.5.  HTTP/2 Connection Preface
https://tools.ietf.org/html/rfc7540#section-3.5

|   The server connection preface consists of a potentially empty
|   SETTINGS frame (Section 6.5) that MUST be the first frame the server
|   sends in the HTTP/2 connection.

> Yeah, that's another option with some disadvantage as you described.
> 
> <snip>
> 

/ Kari Hurtta