Subject: [hybi] WebSocket over HTTP2 is discussed on httpbis

From: Yutaka Hirano <[email-masked]>
Date: Mon, 10 Mar 2014 14:13:39 +0900

Hi,

As I announced before, WebSocket over HTTP2 is discussed on httpbis.
Though tunneling is widely supported in HiBy, httpbis people don't like it
and I failed to persuade them.
Currently there are two proposal [1] and [2].
[2] maps a WebSocket message to HEADERS + DATAs HTTP2 frames and it doesn't
preserve RFC6455 semantics.
For Tobias and Peter, I would show how [2] meets your design priorities
given before.

Tobias's priority:

> 1. allows to provide W3C WebSocket API
>
Yes.

> 2. no "80%-WebSocket-protocol-compatible" design (either compatible with
> full RFC6455 incl. any extensions or outright independent of WS)
>
Yes, 0% RFC6455 Frame compatible (though I would like to  reuse some
handshake stuff).

> 3. does not put servers that provide both native WS and SPDY (but not any
> SPDY/WS) on same origin at a disadvantage
>
It doesn't depend on the framing problem.

> 4. minimizes code coupling between WS and SPDY within implementations

No, though the mapping is simple.

Peter's priority:

> Important:
> 1. W3C WebSocket API and muxing go without saying.
>
Yes.

> 2. Dedicated RFC6455 connections remain a viable option in modern browsers.
>
Yes.

> 3. Efficient and clearly defined method for detecting HTTP/2.0 messaging
> support, choosing HTTP/2.0 vs raw RFC6455, when to fall back, etc.
>
It doesn't depend on the framing stuff.

> 4. Payload compression with appropriate configurability (either via
> permessage-deflate support or a native mechanism)
>
it is possible.

Nice to haves:
> 5. Avoid significant regressions from RFC6455 in wire overhead, latency,
> and per message fixed costs for very small (<100byte) messages.
>
I think there is no significant regressions.

> 6. Clean spec/avoiding redundant and unnecessary features of RFC6455.
>
Yes.

> Only if it doesn’t conflict with 1-6:
> 7. Options for future compatibility with simple RFC6455 extensions

No.

And, protocol negotiation should be also discussed.
In fact, it has more impact on the HTTP2 spec and we should provide
feedback to them as soon as possible if any (See [3] for example).
Please join discussions on http2bis if you have any comments.

Thanks,

[1]:
https://github.com/yutakahirano/ws-over-http2/blob/master/draft-hirano-websocket-over-http2.txt
[2]:
https://github.com/yutakahirano/ws-over-http2/blob/master/ws-over-http2-message-mapping.md
[3]: http://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03

---

From: Takeshi Yoshino <[email-masked]>
Date: Fri, 14 Mar 2014 13:34:06 +0900

Hi,

See http://lists.w3.org/Archives/Public/ietf-http-wg/ to subscribe the
httpbis mailing list if you're not a member of yet. Different from HyBi,
it's hosted by W3C ([email-masked]).

Here's the list of httpbis threads discussing WebSocket topics

- http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0536.html
-- Yutaka announced draft-hirano-websocket-over-http2.txt and listed issues
about protocol negotiation

- http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0590.html
-- Survey on RFC 6455 semantics by Yutaka
-- http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0746.html
--- In this message, Yutaka announced ws-over-http2-message-mapping

- http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0833.html
-- Related thread where they're discussing how supported scheme can be
negotiated

Takeshi

On Mon, Mar 10, 2014 at 2:13 PM, Yutaka Hirano <[email-masked]> wrote:

> [2] maps a WebSocket message to HEADERS + DATAs HTTP2 frames and it
> doesn't preserve RFC6455 semantics.
> _______________________________________________
> hybi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hybi
>
>

---

From: Peter Thorson <[email-masked]>
Date: Fri, 14 Mar 2014 06:40:54 -0500

The gist of the draft proposal [2] would be acceptable to me. I believe there are some performance regressions with respect to RFC6455 but likely none that will be of consequence for a big chunk of the WebSocket user base and for any users that do run into them the solutions seem straight forward (throw more hardware at it or use RFC6455).

I have some more detailed comments about fleshing out that particular draft. Should those be posted here or on the httpbis thread?

On Mar 10, 2014, at 0:13, Yutaka Hirano <[email-masked]> wrote:

> Though tunneling is widely supported in HiBy, httpbis people don't like it and I failed to persuade them.
> [2] maps a WebSocket message to HEADERS + DATAs HTTP2 frames and it doesn't preserve RFC6455 semantics.
> For Tobias and Peter, I would show how [2] meets your design priorities given before.
> 
> Tobias's priority:
> 2. no "80%-WebSocket-protocol-compatible" design (either compatible with full RFC6455 incl. any extensions or outright independent of WS)
> Yes, 0% RFC6455 Frame compatible (though I would like to  reuse some handshake stuff).
> 3. does not put servers that provide both native WS and SPDY (but not any SPDY/WS) on same origin at a disadvantage
> 3. Efficient and clearly defined method for detecting HTTP/2.0 messaging support, choosing HTTP/2.0 vs raw RFC6455, when to fall back, etc.
> 4. Payload compression with appropriate configurability (either via permessage-deflate support or a native mechanism)
> it is possible.
> 
> Nice to haves:
> 5. Avoid significant regressions from RFC6455 in wire overhead, latency, and per message fixed costs for very small (<100byte) messages.
> In fact, it has more impact on the HTTP2 spec and we should provide feedback to them as soon as possible if any (See [3] for example).
> [1]: https://github.com/yutakahirano/ws-over-http2/blob/master/draft-hirano-websocket-over-http2.txt
> [2]: https://github.com/yutakahirano/ws-over-http2/blob/master/ws-over-http2-message-mapping.md

---

From: Yutaka Hirano <[email-masked]>
Date: Fri, 14 Mar 2014 21:46:15 +0900

>
> I have some more detailed comments about fleshing out that particular
> draft. Should those be posted here or on the httpbis thread?

Please feel free to post on the httpbis thread.

Thanks,

On Fri, Mar 14, 2014 at 8:40 PM, Peter Thorson <[email-masked]>wrote:

> The gist of the draft proposal [2] would be acceptable to me. I believe
> there are some performance regressions with respect to RFC6455 but likely
> none that will be of consequence for a big chunk of the WebSocket user base
> and for any users that do run into them the solutions seem straight forward
> (throw more hardware at it or use RFC6455).
>
> I have some more detailed comments about fleshing out that particular
> draft. Should those be posted here or on the httpbis thread?
>