Re: SETTINGS_WEBSOCKET_CAPABLE | Re: WebSocket2

[Takeshi Yoshino <[e-mail]>]

Hi Kari,

Sorry for belated reply.

On Wed, Oct 5, 2016 at 4:03 PM, Kari Hurtta <[e-mail]>
wrote:

<snip>


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

Yes, it's great if the HTTP2 layer guarantee such characteristics. It's
trade-off.

<snip>

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

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

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

Oh, good point. I wasn't aware of that.