Re: HTTP/2 and Websockets

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/10/2014 8:53 p.m., Yutaka Hirano wrote:
> Thank you for the comments!
> 
> If you find small problems (like 4.2 and 4.2.1), creating issues on
> github ( https://github.com/yutakahirano/ws-over-http2) also
> works.
> 
> 
>> I don't understand: DATA is subject to flow control, but I don't
>> see any prose about buffering (or not buffering) of DATA frames.
> 
> As it is not explicitly prohibited, intermediaries may buffer data,
> I think. From the WebSocket point of view, we want intermediaries
> flush the buffered data at each message end.
> 
> 
>> Unless we define a new frame time and explicitly prohibit
>> buffering (but we need to keep it flow controlled), I don't see
>> what would be different. And more importantly, intermediaries
>> might still choose to buffer a new ws frame type anyway: we know
>> that what the spec requires and what people do will differ :).
> 
> As we send SETTINGS_WEBSOCKET_CAPABLE to notify that the HTTP/2
> connection can be used for WebSocket and we use a new frame type, I
> hope intermediaries can deal with it. IIUC an HTTP/2 extension can
> create a new frame type, but cannot modify the meaning of existing
> frame types (e.g. DATA). Even if it is allowed, I would create a
> new frame type not to confuse implementers and [non-confirming]
> intermediaries.
> 
> All the implementor discussion I've seen during the
>> HTTP/2 discussions has focused on how intermediaries want to be 
>> scalable: and buffering is anti-scaling. So - is it a pragmatic 
>> concern, or do we expect DATA stream buffering to take place
>> [outside of protocol gateways converting to HTTP/1.1 where non
>> upload can require buffering - and note that such a gateway can't
>> carry ws anyway unless its aware of it, and if its aware of it,
>> it can make sure it does not buffer].


I think the problem is not buffering in HTTP/2 per-se but the DATA
frame (de-)aggregation that can happen if the frames are buffered by
general network conditions (ie in TCP bottlenecks). This would not be
good for a 1:1 relationship between DATA and ws frames.

Amos
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUK9lgAAoJELJo5wb/XPRjtOEH/i4U3IrX/rjrjZE0dENA1LEF
ifCyjiiWCUIZBBGSW+hzYdFwVRLLhxyHg2vsIQMwpVnTXZzs1QfcAKKl4pJBqscQ
Q92B+fgJZvNmmakrh9mNBA4AVuxDuYm2EYbvAZiSnroxKbYBwdxQMK1ex9reHaY1
TNvlYJyhUX6RQZAllaIxaidEFKazTe1nwzVEuVv80isQtZBqmVL4qhgVw6okf6GP
QzTXHHH1HuaopsJe225RcZaH36NZAtFPJz7DaDbynGLHQqWZg3CVKWKiEYu9GJQe
qa1GVvETgAw40f8AVldTi6AMBsGdZK72dOGTafQoRzv5BMctqqqEofqpmkRC7OY=
=08a0
-----END PGP SIGNATURE-----

Received on Wednesday, 1 October 2014 10:38:02 UTC