Re: HTTP/2 and Websockets

[Yutaka Hirano <[e-mail]>]

Hi,

I am proposing a spec draft:
http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01 .
Since many modifications were made on on the HTTP/2 spec, some description
may be obsolete. Please let me know if you find any flaw.

Firstly we should define the handshake in terms of a stream opening on
> an existing HTTP/2 connection, and since Upgrade: is not permitted in
> HTTP/2 ("
> Note:HTTP/2 purposefully does not support upgrade to another protocol.
> The handshake methods described in Section 3 are believed sufficient
> to negotiate the use of alternative protocols.
> ")
> its not clear to me if that means we need to define a new frame type,
> or whether we can still use the Upgrade header sanely.

The above draft describes the negotiation scheme. Please take a look.

Secondly, we need to define websocket frame mappings. The least work,
> and I suspect the easiest for implementors, would be to put all the
> websocket frames into HTTP/2's data frames, without worrying about
> frame alignment: just treat the fully open stream as a series of bytes
> in the same way TCP is treated by the websocket spec.
> I suspect however that a better result would be achieved by defining
> custom HTTP/2 frames, since websockets already have the basic support
> for multiplexing (large application writes can be fragmented into
> smaller frames as needed), we shouldn't run into HOL blocking issues.

Yeah, we can't simply use DATA frames because intermediaries may buffer
data. The HTTP/2 spec had "MSG_DONE" once and I wanted to use it, but it
was removed from the spec. Currently I think introducing a new frame type
is the right way.


> Lastly, it seems (to me) that it would be desirable to allow
> PUSH_PROMISE setup of websockets connections

Can you tell me why it is desirable?

Thanks,


On Mon, Sep 29, 2014 at 12:10 PM, Robert Collins <[e-mail]>
wrote:

> Has anyone done any specification on integrating websockets into
> HTTP/2? I couldn't find a spec, so I poked around a bit...
>
> It looks to me like there are three issues.
>
> Firstly we should define the handshake in terms of a stream opening on
> an existing HTTP/2 connection, and since Upgrade: is not permitted in
> HTTP/2 ("
> Note:HTTP/2 purposefully does not support upgrade to another protocol.
> The handshake methods described in Section 3 are believed sufficient
> to negotiate the use of alternative protocols.
> ")
>
> its not clear to me if that means we need to define a new frame type,
> or whether we can still use the Upgrade header sanely.
>
>
> Secondly, we need to define websocket frame mappings. The least work,
> and I suspect the easiest for implementors, would be to put all the
> websocket frames into HTTP/2's data frames, without worrying about
> frame alignment: just treat the fully open stream as a series of bytes
> in the same way TCP is treated by the websocket spec.
> I suspect however that a better result would be achieved by defining
> custom HTTP/2 frames, since websockets already have the basic support
> for multiplexing (large application writes can be fragmented into
> smaller frames as needed), we shouldn't run into HOL blocking issues.
>
> Lastly, it seems (to me) that it would be desirable to allow
> PUSH_PROMISE setup of websockets connections, but the PUSH_PROMISE
> state machine goes straight into half-closed, rather than into 'open',
> and that prohibits doing websockets with a pushed connection. There
> isn't any prose in HTTP/2 about /why/ the state machine does that :(.
>
> -Rob
>
> --
> Robert Collins <[e-mail]>
> Distinguished Technologist
> HP Converged Cloud
>
>