Re: HTTP/2 and Websockets

[Ilari Liusvaara <[e-mail]>]

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