Re: HTTP/2 and Websockets

On Fri, Nov 21, 2014 at 5:44 PM, Robert Collins <robertc@robertcollins.net>
wrote:

> 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.
>
> Hmm... Is that specified?
Are such buffering proxies prohibited explicitly?

> 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.
>
> We can prevent the situation with WS_DATA, because a ws ignorant h2 proxy
must not transfer the custom frame.
The spec says:
  Implementations MUST discard frames that have unknown or unsupported
types.

Unable to communicate is better than relying on intermediaries that do not
understand what they are doing, I think.

> 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.
>
I will think more on this point.


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