Re: WebSocket over HTTP/2.0

[Roberto Peon <[e-mail]>]

As I've said in hybi (but needs to be said here since we've changed venues):

I'd like to see a mapping of WS onto HTTP/2.

I am completely uninterested in any option that keeps full RFC6455
semantics (frame extensions make zero sense) without significant ofsetting
benefits, and I would work to ensure such was not again created at IETF,
and would work to ensure that it was not implemented at Google.


Plan D makes no sense to me. It requires implementation of two separate
parsers and yields no benefit for intermediary loadbalancing
infrastructure. Arguably it additionally increases latency, since the
handshake is still preserved as written in RFC6455.

Plan A offers some benefits for loadbalancers, etc. so long as END_SEGMENT
always correlates to the end of a message, and so seems potentially
tenable. Loadbalancers need not implement the RFC6455 parser in order to
load balance, which is a significant benefit. It is sad that there would
still be the latency of the handshake. I dislike that this would still
include much of the silliness in RFC6455 w.r.t. frame extensions.

I'd prefer/love to see a 1:1 mapping of the WS API to http2's framing layer:
Streams-of-messages would be initiated using HEADERS which included scheme
host path and content-type (for binary vs not binary), with messages
delimited using END_SEGMENT. If there is need to change the content type,
an additional HEADERS frame could be emitted changing the content-type.
This reduces the amount of latency overhead necessary, doesn't
significantly decrease byte efficiency, and requires less code long-term,
which enhances interop.

Loadbalancing HTTP and WS could be accomplished using the same code and
rulesets. A loadbalancer would simply check the scheme, host, path, and see
if it should demux the messages to separate backends, or forward the stream
normally. By default I'd assume a loadbalancer would forward the stream
unless it saw the scheme was http or https.

-=R


On Fri, Feb 14, 2014 at 6:23 AM, Yutaka Hirano <[e-mail]> wrote:

> Hi,
>
> I've submitted a draft of the WebSocket over HTTP/2.0 specification.
> http://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-00
> https://github.com/yutakahirano/ws-over-http2
>
> It has been discussed at hybi-ietf and spdy-dev, so I would like to recap
> the past discussions.
>
> Two years ago, Takashi started a discussion of WebSocket over SPDY at
> spdy-dev[1]. Mainly framing and the protocol negotiation method was
> discussed. For framing, three plans (A, B and C) were proposed. Many people
> liked plan C while some liked plan A.
> Unfortunately, the discussion faded away.
>
> I restarted the discussion in this January. I posted a message to spdy-dev
> and hybi-ietf. There were no response from spdy-dev and hence we discussed
> at hybi-ietf[2].
> For framing, the existing plans were updated and further plans were
> proposed. Some of them keep the RFC6455 semantics and map a WebSocket frame
> to some HTTP/2.0 frames. Others don't preserve the RFC6455 semantics. To
> narrow the discussion focus I proposed to decide if we should preserve the
> RFC6455 semantics or not. Many but not all agree to preserve the RFC6455.
> For protocol negotiation, thanks to the Tobias and Adam's comments, I
> revised the protocol negotiation method.
> As suggested by Salvatore, I decided to submit a draft and move the
> discussion to httpbis wg.
>
> The submitted draft contains several framing plans, but all of them
> preserve the RFC6455 semantics. Accepting a plan that doesn't preserve the
> RFC6455 requires rewriting the draft from scratch.
>
> WebSocket over HTTP/2.0 requires some additional definitions to be
> introduced in HTTP/2.0.
> - Introduce SETTINGS_SUPPORTED_SCHEMES as described in the draft.
> - A server MUST send a RST_STREAM when it receive a HEADERS with
>   an unsupported scheme.
> - Introduce HTTP/2.0[xx] as the "Application Layer Protocol Negotiation
>   (ALPN) Protocol IDs" registry established in [TLSALPN] for each xx,
>   meaning that the HTTP/2.0 protocol with scheme xx (e.g. HTTP/2.0[wss]).
>
> Your comments will be appreciated.
>
> Thanks,
>
> [1]:
> https://groups.google.com/forum/#!searchin/spdy-dev/WebSocket/spdy-dev/rwOh5dH4ibU/6QK-egrwDgsJ
> [2]: http://www.ietf.org/mail-archive/web/hybi/current/msg10266.html
>