Subject: WebSocket over HTTP/2.0

From: Yutaka Hirano <[email-masked]>
Date: Fri, 14 Feb 2014 23:23:03 +0900

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

---

From: Roberto Peon <[email-masked]>
Date: Fri, 14 Feb 2014 12:25:58 -0800

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Feb 2014 13:49:26 -0800

On 14 February 2014 12:25, Roberto Peon <[email-masked]> wrote:
> 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.

I too wondered why there was a need to tunnel thewebsocketprotocol as
opposed to creating a way to map the semantics efficiently.

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 16 Feb 2014 10:39:48 +1100

I've created an issue to track this, since we haven't done so explicitly before:
  https://github.com/http2/http2-spec/issues/386

I'd like to have a *brief* discussion about it in London, so that we can come to agreement about what the plan is going forward.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Yutaka Hirano <[email-masked]>
Date: Wed, 19 Feb 2014 23:34:53 +0900

> include much of the silliness in RFC6455 w.r.t. frame extensions.

I think Plan A in the draft doesn't offers benefits for loadbalancers. Once
Plan A did, but I removed the functionality at [1].
However, we can recover the functionality I think.

IIUC we can discuss the opening handshake independently from the framing
plan at [2].
As I said before, I think you like Plan C. If not, can you share you
thoughts?

> opposed to creating a way to map the semantics efficiently.

Martin, let me confirm.
Does your "a way to map the semantics efficiently" mean Plan C? Or you have
another idea?

Thanks,

[1]: http://www.ietf.org/mail-archive/web/hybi/current/msg10403.html
[2]: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JanMar/0551.html

On Sat, Feb 15, 2014 at 6:49 AM, Martin Thomson <[email-masked]>wrote:

> semantics

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Feb 2014 14:40:06 -0800

> Does your "a way to map the semantics efficiently" mean Plan C? Or you have

I don't have a concrete plan, but here's what I believe the semantics
you want to preserve are.  From there, I think that you will find the
delta is minimal from what is already in the HTTP/2 spec:

WebSockets produces an ordered sequence of messages.  The messages are
exchanged between a client and a resource that is identified by a URI
of either ws: or wss: scheme.  These messages are of arbitrary length.
 Messages can contain either binary data or UTF-8 text.

You'll note that I don't mention frames at all here.

>From that description, the only thing that HTTP/2 can't provide is the
binary/text distinction.  If you add compression, then that's another
item to add.  I think that what Roberto describes with HEADERS + DATA
(and END_SEGMENT) is workable for this.

---

From: Takeshi Yoshino <[email-masked]>
Date: Sat, 1 Mar 2014 04:34:05 +0900

BTW, introduction of the SETTINGS_SUPPORTED_SCHEMES parameter for the
SETTINGS frame in the proposal could be discussed separately from the
framing discussion. It seems Mark's Alt-Svc I-D also has similar proposal
called SETTINGS_UNIVERSAL_SCHEMES [1] though in a different context.

[1]
https://tools.ietf.org/html/draft-nottingham-httpbis-alt-svc-03#section-3.4