Re: HTTP/2 and Websockets

On 21 November 2014 20:03, Yutaka Hirano <yhirano@google.com> wrote:
>

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

But intermediaries won't be buffering: they'll be forwarding as soon
as they can, since h2 is being established from the get-go as an
interactive protocol.

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

Why not? Any ws ignorant h2 proxy that holds buffers for indeterminate
periods because e.g. it wants to virus scan uploads/downloads is just
as likely to a) reject unknown frames or b) inspect and scan ws
frames. I don't see how we prevent that by using a custom frame.

> 2. With explicit negotiation, I know that all peers in the communication
> path understand ws-over-http2 perfectly and there is no chance to

The proposed negotiation in the draft I saw didn't guarantee that (see
my comments in this thread) because options isn't graph-capable: an
intermediary that is capable advertises its capability, not the
capability of peers on the other side of it, and no replacement
negotiation has been proposed that I've seen.

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

WebSockets' HTTP/1.1 upgrade hack was a clever way to avoid a new port
for a new protocol layered on top of 20 years of proxy evolution.
We're not *at all* in the same situation now, and I think we should
bear that in mind.

-Rob


-- 
Robert Collins <rbtcollins@hp.com>
Distinguished Technologist
HP Converged Cloud

Received on Friday, 21 November 2014 08:45:17 UTC