Re: Quick review for draft-svirid-websocket2-over-http2 (Was: Re: Draft HTTPbis Agenda For Seoul IETF 97)

[Tom Bergan <[e-mail]>]

On Wed, Oct 19, 2016 at 5:48 PM, Kazuho Oku <[e-mail]> wrote:

> Hi,
>
> 2016-10-20 1:50 GMT+09:00 Ilari Liusvaara <[e-mail]>:
> > On Wed, Oct 19, 2016 at 10:03:18AM -0400, Van Catha wrote:
> >> I am particularly interest in the future of 2 way binary streaming.  So
> the
> >> topics of WebSocket, Streams API and other related. I have even put
> forward
> >> a draft related to the WebSocket part.
> >> https://datatracker.ietf.org/doc/draft-svirid-websocket2-over-http2/
> >
> > Some quick review comments:
> >
> > - The handshake seems to negotiate compression and then the frames
> >   contain compression method indicator. Are there really multiple
> >   compression methods available on per-frame basis, or should the
> >   compression just be 1 bit (compressed or not)?
> > - The abbrevations in frame diagram are bit difficult to understand
> >   (have those be expanded in above text?).
> > - Somebody needs to try what this does against many HTTP/2 origins
> >   that don't support WebSockets2 and against intermediaries with
> >   custom server that actually supports it. Just to see what the
> >   heck happens (if it is nasty, one might need to use SETTINGS to
> >   signal support, either for WebSockets directly or for some sort
> >   of strict scheme).
>
> That's a good point.
>
> In case of H2O, all schemes are handling equally at the protocol
> layer. In other words, whatever the :scheme is, the server is designed
> to wait for a request, and then send response.
>
> My understanding is that the HTTP/2 specification is written in mind
> to allow such implementations, and that it would be a violation of
> HTTP/2 to introduce different interactions by using :scheme as an
> indicator. For example, transition of the stream states described in
> section 5.1 is not restricted to specific schemes.
>
> So if we are to start using the HTTP/2 framing layer to transmit
> websocket or other bi-directional communication, I think we should
> require negotiation using SETTINGS frame. Also, it might be beneficial
> to use a frame type other than DATA to convey bi-directional
> information to avoid potential issues (since the transition of the
> stream states are mostly related to how DATA frames are handled).


Ignoring the practical issues for a moment (which are obviously important),
which part of the H2 spec forbids bidirectional communication as desired by
WebSockets2? The stream state diagram in section 5.1 says that a stream
transitions from "idle" to "open" when the client/server sends/receives a
HEADERS frame (with CONTINUATIONs). A stream doesn't transition to a
"closed" state until a peer sends an ENDS_STREAM flag. Section 5.1 says: "A
stream in the 'open' state may be used by both peers to send frames of any
type." This seems to explicitly allow bidirectional communication with DATA
frames as desired by WebSockets2. Further, WebSockets2's bidirectional
communication looks very similar to bidirectional streaming in gRPC:
http://www.grpc.io/docs/guides/concepts.html#bidirectional-streaming-rpc
http://www.grpc.io/docs/guides/wire.html

In practice, I could see that some servers will try to consume the entire
request before returning any kind of response, and this definitely might
interact poorly with WebSockets2.