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


From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 13 Oct 2016 16:20:57 +0900
Message-ID: <CAH9hSJaWXJWH4mK3J3WyHGtc4ohKyDL-AGcGYsJMj=6hob_ChQ@mail.gmail.com>
To: Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Cc: Van Catha <vans554@gmail.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, HTTP working group mailing list <ietf-http-wg@w3.org>
Hi Kari,

Sorry for belated reply.

On Wed, Oct 5, 2016 at 4:03 PM, Kari Hurtta <hurtta-ietf@elmme-mailer.org>


> 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


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


> 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.
Received on Thursday, 13 October 2016 07:21:47 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 October 2016 07:21:51 UTC