Re: HTTP/2 and Websockets

[Yutaka Hirano <[e-mail]>]

>
> I was suggesting that we just treat the HTTP/2 stream like the TCP
> connection in RFC 6455 - the conversation from stream to message based
> semantics and so on can take place above that in the ws implementation
> - and that we should still apply the transmission windows etc to ws
> streams.

So your opinion is similar to
http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-00#section-5.2.1
, right?
As I said, I would like a guarantee that intermediaries do not buffer data
across the message boundary. END_SEGMENT was a mechanism to archive this,
but it was gone. So I want to specify a new frame type (WEBSOCKET_DATA) to
guarantee that (Note: I'm not sure if tunneling is good or bad, but
forbidding buffering across the message boundary is important in any case).


On Tue, Oct 14, 2014 at 7:01 PM, Robert Collins <[e-mail]>
wrote:

> On 1 October 2014 23:37, Amos Jeffries <[e-mail]> wrote:
>
> >> 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
>
> So hang on a second here. If we say that ws frames can't be split over
> multiple HTTP/2 frames that implies that we have to buffer them until
> there is enough in the window to transmit a potentially very large
> packet all at once. It also conflicts with RFC6455 - the specific
> intent there is to not be a stream based system.
>
> I was suggesting that we just treat the HTTP/2 stream like the TCP
> connection in RFC 6455 - the conversation from stream to message based
> semantics and so on can take place above that in the ws implementation
> - and that we should still apply the transmission windows etc to ws
> streams.
>
> -Rob
>
>
>
> --
> Robert Collins <[e-mail]>
> Distinguished Technologist
> HP Converged Cloud
>
>