- From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
- Date: Thu, 13 Oct 2016 19:52:32 +0300 (EEST)
- To: Takeshi Yoshino <tyoshino@google.com>
- CC: Kari Hurtta <hurtta-ietf@elmme-mailer.org>, Van Catha <vans554@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Takeshi Yoshino <tyoshino@google.com>: (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
Received on Thursday, 13 October 2016 16:53:05 UTC