Re: HTTP/2 and Websockets

Thank you for the comments!

We have been not working actively for months because of two reasons:
1) The http/2 spec was changing rapidly and we couldn't write a spec on top
of it.
2) We weren't confident if wide range of people were interested in this
protocol.

1) will be resolved soon, I hope. For 2), If you are interested in
WebSocket over HTTP/2, it is very helpful to express it!
About one year ago, we were talking if we wanted perfect RFC6455 compatible
WebSocket or not (i.e. full-extension support). IIRC most of us didn't want
the full RFC6455 compatibility, but if you have any opinion, it is welcome.
In short, we would like to hear your voice.

I would just signal SETTINGS_WEBSOCKET_CAPABLE with 0x1-bit set to 1 (and
> the rest reserved for extension) from server (or from proxy towards
> client).
> After receiving SETTINGS_WEBSOCKET_CAPABLE with 0x1 flag, the client/
> proxy knows the proxy/server can handle websockets (and is used via
> :scheme 'ws'/'wss'). No need to ACK anything.

My proposal doesn't need ACK.
The client sends a SETTINGS frame before sending the first handshake in the
stream. After that, the client starts the usual WebSocket opening handshake.

One way would be to take the base Websockets spec for data communications
> and rip out everything unneeded and adapt some things:
> - Server's/proxy(toward client) SETTINGS has notification about Websockets
>   support.
> - Client's opening handshake has no upgrade headers (upgrade or connection:
>   upgrade). Instead it has :scheme set to either 'ws' or 'wss'.
> - Client's opening handshake has :authority instead of host.
> - Client's opening handshake has no Sec-websocket-key
> - Server's opening handshake has 200 status instead of 101.
> - Server's opening handshake has no Sec-websocket-accept
> - Each DATA frame carries one websocket frame.
> - FIN, RSVx and opcode are signaled as the first byte of DATA frame.
> - There is no masking, and MASK is implcitly 0.
> - Frame length is implicitly data frame length - 1.
> - Zero-byte data frames are not valid.
> - Proxies fragment or coalesce if needed (TODO: How to handle 16kB
>   and up control frames?)
> - Proxies can perform adaptation between RFC 6455 and Websockets over
>   HTTP/2.
> - No TLS handshakes are done (TLS is below HTTP/2).
> - TCP connection is replaced by HTTP/2 stream.
>

Given that we have SETTINGS_WEBSOCKET_CAPABLE, I would use a new frame type
not to confuse intermediaries / endpoints. The actual data format will be
discussed, but IMHO it is less important and can be discussed later.

Thanks,

On Mon, Sep 29, 2014 at 6:51 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> On Mon, Sep 29, 2014 at 02:26:34PM +0900, Yutaka Hirano wrote:
> > Hi,
> >
> > I am proposing a spec draft:
> > http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01
> .
> > Since many modifications were made on on the HTTP/2 spec, some
> description
> > may be obsolete. Please let me know if you find any flaw.
>
> The capability negotiation looks weird.
>
> I would just signal SETTINGS_WEBSOCKET_CAPABLE with 0x1-bit set to 1 (and
> the rest reserved for extension) from server (or from proxy towards
> client).
>
> After receiving SETTINGS_WEBSOCKET_CAPABLE with 0x1 flag, the client/
> proxy knows the proxy/server can handle websockets (and is used via
> :scheme 'ws'/'wss'). No need to ACK anything.
>
> In the future, some more elaborate extensions might need to be enabled
> from both sides, but be base functionality doesn't. Only features that
> change existing semantics need to be acknowledged.
>
> One example of something to signal from client to proxy/server would
> be reverse connections (but this needs some way for proxies and browsers
> to route the connection, maybe associated stream ID, and PUSH_PROMISE
> can't be used due to its unidirectionality[1]).
>
> Reverse connections can't be mapped to RFC 6455, so those would need
> HTTP/2 path all the way between client and server.
>
> > Yeah, we can't simply use DATA frames because intermediaries may buffer
> > data. The HTTP/2 spec had "MSG_DONE" once and I wanted to use it, but it
> > was removed from the spec. Currently I think introducing a new frame type
> > is the right way.
>
> One way would be to take the base Websockets spec for data communications
> and rip out everything unneeded and adapt some things:
>
> - Server's/proxy(toward client) SETTINGS has notification about Websockets
>   support.
> - Client's opening handshake has no upgrade headers (upgrade or connection:
>   upgrade). Instead it has :scheme set to either 'ws' or 'wss'.
> - Client's opening handshake has :authority instead of host.
> - Client's opening handshake has no Sec-websocket-key
> - Server's opening handshake has 200 status instead of 101.
> - Server's opening handshake has no Sec-websocket-accept
> - Each DATA frame carries one websocket frame.
> - FIN, RSVx and opcode are signaled as the first byte of DATA frame.
> - There is no masking, and MASK is implcitly 0.
> - Frame length is implicitly data frame length - 1.
> - Zero-byte data frames are not valid.
> - Proxies fragment or coalesce if needed (TODO: How to handle 16kB
>   and up control frames?)
> - Proxies can perform adaptation between RFC 6455 and Websockets over
>   HTTP/2.
> - No TLS handshakes are done (TLS is below HTTP/2).
> - TCP connection is replaced by HTTP/2 stream.
>
> This requires some support on proxies (e.g. priority boosting and
> fragmenting), but proxies should know what they are dealing with,
> and Websockets needs proxy support anyway (at least unless one does not
> want to burn through sequence numbers really fast and to cause excessive
> load on proxies).
>
> Also, extensions that modify base header semantics (as opposed to just
> using RSVx bits or adding their own header included in frame size)
> don't work, but I think that is not a big problem. PMCE is OK.
>
>
> [1] I earlier sent list of ideas for decoupling framing and HTTP layers,
> PUSH_PROMISE is unidirectional even in that (that's the difference
> between PUSH_PROMISE and HEADERS!).
>
>
> -Ilari
>