Re: HTTP/2 and Websockets

On 25 November 2014 at 14:18, Amos Jeffries <squid3@treenet.co.nz> wrote:

> I think Hirano-san's proxy case is a good one to work with. But limit
> it to being a HTTP/2 compliant proxy. That limits it to
> slicing/aggregating DATA frames any way it likes but not re-ordering
> or changing payload bytes unless there are transformations which the
> HTTP/2 headers permit (the TCP analogy).
>
> A truely broken magic proxy does not exist yet in any HTTP/2
> implementations and HTTP/2 itself is taking the "hard line" of
> defining RST_STREAM or GOAWAY to be used when any kind of binary level
> broken proxy is detected.

Right.

> So the magic proxy can take your 1-byte flags + 6 byte WS payload DATA
> frame and slice it. Delivering 1 byte DATA frame followed by 6 byte
> DATA frame to the server. This is particularly likely to happen if
> your WS client writes the flags and WS payload in separate operations

Or it can do 7 x 1 byte frames, or one 8 byte frame. Shrug. Its a
series of octets.

> to the HTTP/2 library/backend.
>  - all you need to resolve this is a length+flags+payload structure to
> the WS data. You can do that at the HTTP//2 stream level, or inside
> the DATA frame payload.

The WS internal framing already has this. Its how it works on TCP, and
its trivial.

>  - if you dont know the length in advance then stream level is best
> for HTTP/2 compatibility.

ws does, always, because the api is messages, not octets.

-Rob


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

Received on Tuesday, 25 November 2014 01:30:59 UTC