Re: HTTP/2 and Websockets

On Fri, Nov 21, 2014 at 3:15 PM, Andy Green <andy@warmcat.com> wrote:

>
>
> On 21 November 2014 13:13:02 GMT+08:00, Andy Green <andy@warmcat.com>
> wrote:
> >
> >
> >On 21 November 2014 12:33:45 GMT+08:00, Yutaka Hirano
> ><yhirano@google.com> wrote:
> >>>
> >>>  - WSDATA's 8-bit flags field, is the ws flags [fin][rsv1-3][opcode]
> >>
> >>We may want END_STREAM as well.
> >
> >Good point... and to be friendly with http2's obfuscation goals,
> >PADDING.
> >
> >It means we need an extra byte to hold all the flags... well it's not
> >too bad per-frame.
> >
> >If so, we could also do everything the same reusing using DATA with a
> >flag "WS", indicating the payload is [WS_FLAGS byte + ws payload].
> >That has an advantage --->
> >
> >>Corresponding http2 frames can substitue ping / pong / close (note:
> >>WebSocket ones have payload though h2 ones don't). Shoud we have
> >>opcodes
> >>for them?
> >
> >We should probably keep the ws ones too.  Things like ws echo services
> >do use the payload.  Actually endpoints can prefer the http2 ones if
> >the see they can use them and know how to.  But supporting both
> >everyone's happy.
> >
> >Ws has his own close codes and payload, if we try mapping those on
> >http2 codes etc it might be a step too far.  So keeping ws close frame
> >will be good.
> >
> >Close is a bit tricky if we try to say that a WSDATA close is an
> >implicit http2 stream close everybody has to understand that, even if
> >they were intermediaries that didn't really understand WSDATA and were
> >just passing it through.  That's probably too much to ask.
> >
> >If we re-use DATA with a WS flag, the extra advantage is all http2
> >intermediaries and endpoints already know the meaning of DATA frame
> >with END_STREAM, so even if they do not follow what WS flag on DATA
> >means, they can still follow the stream lifecycle without extra work.
> >
> >How realistic is it to get a DATA flag bit assigned now?
>
> Ah since the endpoints negotiated ws using HEADERS, actually we could do
> without a WS flag on DATA.
>
> The fact that it's DATA for stream ID xxx and that ID went through a ws
> handshake means both sides and all intermediaries present during the ws
> handshake can know it is ws protocol in the DATA without an explicit flag.
>
> So we could just use DATA for this without any modification.  Peers that
> understand websockets can know in some streams there's a WS_FLAGS byte at
> the start of the DATA payload.  Peers that don't understand websockets just
> move opaque DATA payloads around as usual and only see normal DATA
> semantics going on.
>
> I don't like the idea of using the existing DATA frame.

1. An intermediary must flush data when it sees an end of message (FIN).
IIUC we don't have such flag in the plain http2 (we had END_SEGMENT but it
is gone). So "just move opaque DATA payloads around" is not enough.
2. With explicit negotiation, I know that all peers in the communication
path understand ws-over-http2 perfectly and there is no chance to
misunderstand DATA in http2 and DATA in ws2, in theoretically. In reality,
that is not true. The history of WebSocket is the history of battles with
mis-implemented proxies (Note that the native WebSocket has the explicit
negotiation but proxies modify payloads without understanding it). I would
like to reduce the possibility of such confusion.