W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2016

Re: SETTINGS_WEBSOCKET_CAPABLE | Re: WebSocket2

From: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Thu, 13 Oct 2016 19:52:32 +0300 (EEST)
Message-Id: <201610131652.u9DGqWfQ007809@shell.siilo.fmi.fi>
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

This archive was generated by hypermail 2.3.1 : Thursday, 13 October 2016 16:53:07 UTC