Re: HTTP/2 and Websockets

[Greg Wilkins <[e-mail]>]

I think this is a timely subject as I believe it is very important to take
Yutaka's ideas forward to a working extension sooner rather than later.

My fear is that unless we test websocket over HTTP/2 before we go final, we
may discover some fatal flaw that prevents efficient handling of websocket
as a h2 stream.

Even if there are no nasties discovered, not having an extension defined at
the start will mean that a lot of h2 infrastructure will get deployed
without websocket support.  Once this occurs, it may be very difficult to
get good websocket coverage for some time with an extension approach.   I
fear that the response will be to come up with a websocket mapping that
abuses the h2 protocol so that it can tunnel through websocket unaware
intermediaries... and that is unlikely to be efficient because we have
dropped end_segment semantics from h2 streams.

Cheers

PS. My real preference is that this group get's recharted to support both
http and websocket semantics over h2 - and we go back to the drawing board
with the framing layer using >1 examples to generalise from.



On 29 September 2014 21:36, Yutaka Hirano <[e-mail]> wrote:

> Thank you for the comments!
>
> We have been not working actively for months because of two reasons:
> 1) The http/2 spec was changing rapidly and we couldn't write a spec on
> top of it.
> 2) We weren't confident if wide range of people were interested in this
> protocol.
>
> 1) will be resolved soon, I hope. For 2), If you are interested in
> WebSocket over HTTP/2, it is very helpful to express it!
> About one year ago, we were talking if we wanted perfect RFC6455
> compatible WebSocket or not (i.e. full-extension support). IIRC most of us
> didn't want the full RFC6455 compatibility, but if you have any opinion, it
> is welcome.
> In short, we would like to hear your voice.
>
> I would just signal SETTINGS_WEBSOCKET_CAPABLE with 0x1-bit set to 1 (and
>> the rest reserved for extension) from server (or from proxy towards
>> client).
>> After receiving SETTINGS_WEBSOCKET_CAPABLE with 0x1 flag, the client/
>> proxy knows the proxy/server can handle websockets (and is used via
>> :scheme 'ws'/'wss'). No need to ACK anything.
>
> My proposal doesn't need ACK.
> The client sends a SETTINGS frame before sending the first handshake in
> the stream. After that, the client starts the usual WebSocket opening
> handshake.
>
> One way would be to take the base Websockets spec for data communications
>> and rip out everything unneeded and adapt some things:
>> - Server's/proxy(toward client) SETTINGS has notification about Websockets
>>   support.
>> - Client's opening handshake has no upgrade headers (upgrade or
>> connection:
>>   upgrade). Instead it has :scheme set to either 'ws' or 'wss'.
>> - Client's opening handshake has :authority instead of host.
>> - Client's opening handshake has no Sec-websocket-key
>> - Server's opening handshake has 200 status instead of 101.
>> - Server's opening handshake has no Sec-websocket-accept
>> - Each DATA frame carries one websocket frame.
>> - FIN, RSVx and opcode are signaled as the first byte of DATA frame.
>> - There is no masking, and MASK is implcitly 0.
>> - Frame length is implicitly data frame length - 1.
>> - Zero-byte data frames are not valid.
>> - Proxies fragment or coalesce if needed (TODO: How to handle 16kB
>>   and up control frames?)
>> - Proxies can perform adaptation between RFC 6455 and Websockets over
>>   HTTP/2.
>> - No TLS handshakes are done (TLS is below HTTP/2).
>> - TCP connection is replaced by HTTP/2 stream.
>>
>
> Given that we have SETTINGS_WEBSOCKET_CAPABLE, I would use a new frame
> type not to confuse intermediaries / endpoints. The actual data format will
> be discussed, but IMHO it is less important and can be discussed later.
>
> Thanks,
>
> On Mon, Sep 29, 2014 at 6:51 PM, Ilari Liusvaara <
> [e-mail]> wrote:
>
>> On Mon, Sep 29, 2014 at 02:26:34PM +0900, Yutaka Hirano wrote:
>> > 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.
>>
>> The capability negotiation looks weird.
>>
>> I would just signal SETTINGS_WEBSOCKET_CAPABLE with 0x1-bit set to 1 (and
>> the rest reserved for extension) from server (or from proxy towards
>> client).
>>
>> After receiving SETTINGS_WEBSOCKET_CAPABLE with 0x1 flag, the client/
>> proxy knows the proxy/server can handle websockets (and is used via
>> :scheme 'ws'/'wss'). No need to ACK anything.
>>
>> In the future, some more elaborate extensions might need to be enabled
>> from both sides, but be base functionality doesn't. Only features that
>> change existing semantics need to be acknowledged.
>>
>> One example of something to signal from client to proxy/server would
>> be reverse connections (but this needs some way for proxies and browsers
>> to route the connection, maybe associated stream ID, and PUSH_PROMISE
>> can't be used due to its unidirectionality[1]).
>>
>> Reverse connections can't be mapped to RFC 6455, so those would need
>> HTTP/2 path all the way between client and server.
>>
>> > 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.
>>
>> One way would be to take the base Websockets spec for data communications
>> and rip out everything unneeded and adapt some things:
>>
>> - Server's/proxy(toward client) SETTINGS has notification about Websockets
>>   support.
>> - Client's opening handshake has no upgrade headers (upgrade or
>> connection:
>>   upgrade). Instead it has :scheme set to either 'ws' or 'wss'.
>> - Client's opening handshake has :authority instead of host.
>> - Client's opening handshake has no Sec-websocket-key
>> - Server's opening handshake has 200 status instead of 101.
>> - Server's opening handshake has no Sec-websocket-accept
>> - Each DATA frame carries one websocket frame.
>> - FIN, RSVx and opcode are signaled as the first byte of DATA frame.
>> - There is no masking, and MASK is implcitly 0.
>> - Frame length is implicitly data frame length - 1.
>> - Zero-byte data frames are not valid.
>> - Proxies fragment or coalesce if needed (TODO: How to handle 16kB
>>   and up control frames?)
>> - Proxies can perform adaptation between RFC 6455 and Websockets over
>>   HTTP/2.
>> - No TLS handshakes are done (TLS is below HTTP/2).
>> - TCP connection is replaced by HTTP/2 stream.
>>
>> This requires some support on proxies (e.g. priority boosting and
>> fragmenting), but proxies should know what they are dealing with,
>> and Websockets needs proxy support anyway (at least unless one does not
>> want to burn through sequence numbers really fast and to cause excessive
>> load on proxies).
>>
>> Also, extensions that modify base header semantics (as opposed to just
>> using RSVx bits or adding their own header included in frame size)
>> don't work, but I think that is not a big problem. PMCE is OK.
>>
>>
>> [1] I earlier sent list of ideas for decoupling framing and HTTP layers,
>> PUSH_PROMISE is unidirectional even in that (that's the difference
>> between PUSH_PROMISE and HEADERS!).
>>
>>
>> -Ilari
>>
>
>


-- 
Greg Wilkins <[e-mail]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.