Re: [hybi] Fwd: New Version Notification for draft-mcmanus-httpbis-h2-websockets-01.txt

On Fri, Nov 10, 2017 at 4:05 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:

> 2017-11-10 15:14 GMT+09:00 Kari Hurtta <hurtta-ietf@elmme-mailer.org>:
> > Then that ":upgrade" works as explicit tunneling mechanism, IF you can
> trust
> > that response is treated as mailformed (stream error of type
> PROTOCOL_ERROR)
> > when proxies/frameworks does not subscribe that tunneling mechanism.
> >
> > Can you trust that?
>
> Note that we would be doing negotiation beforehand using a SETTINGS
> parameter. Otherwise, a client cannot send a request with `:upgrade:`
> pseudo header.
>
> I believe that a successful negotiation would be sufficient to
> guarantee that the `:upgrade:` response header will be recognized as a
> signal (or a 101 status code as a signal).
>

Agreed with Kazuho about this point.

Depending on such detection of a spec violation is interesting, but I think
we shouldn't. It's fragile. We're already clearing the path between the
endpoints by the forwarding of the SETTINGS. That should be enough, yes.

I'd rather suggest that we don't violate RFC 7540. As we'll be using a
pseudo header, we anyway need special logic to generate/parse it. So, it
doesn't matter so much whether the name is "upgrade" or not. We could e.g.
use ":upgrade", and ":upgrade-response" in each direction respectively.

I listed a few more points below that I think we should get consensus. But
basically, I like the direction (use of HEADERS, signaling by SETTINGS).

----

I remember that we had some discussion about this kind of usage of the
SETTINGS frame mechanism with H2 connection bundling/un-bundling proxies on
the way, when we were discussing Yutaka's WS/H2 I-D
<https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01> 3
y ago.

Suppose that we have a reverse proxy that has a single H2 connection with a
browser which is unbundled by the proxy to different target backends (still
H2 but with fewer streams) where some backends can handle tunneling, but
some cannot. The proxy needs to either:
- forward the SETTINGS to the browser to allow it to use tunneling, but
convert tunneling requests to the tunneling/H2 non-capable backends to one
over H1
- don't forward the SETTINGS as not all backends are capable of it

As SETTINGS is about hop-by-hop characteristics, we need to consolidate the
bit as above at bundling points. I think this is fine and we don't want to
introduce any complicated mechanism to perform e2e negotiation. Do you all
agree on this?

----

In Yutaka's I-D, we tried to allow speculatively initiating a WebSocket
over H2 without waiting for capability announcement by the server. In
Patrick's proposal, we instead wait for the SETTINGS frame before
initiating a WebSocket.

How and when should a browser determine whether a certain H2 connection is
tunneling capable or not?

What's in my mind is:

- When there's no connection at all,
  - ws: RFC 6455 connection attempt is made on TCP but with the
HTTP2-Settings header in addition to the standard RFC 6455 headers, which
might get upgraded to WS/H2 (indicated by e.g. an additional header, or a
special Upgrade value "websocket-h2c") or just proceed as RFC 6455
  - wss: Use ALPN? See
https://tools.ietf.org/html/draft-hirano-httpbis-websocket-over-http2-01#section-3.4
- When there's ongoing H2 connection establishing, the browser waits until
the initial SETTINGS is received following the preface. If there
isn't ENABLE_CONNECT_PROTOCOL, the browser should use WS/TCP. Otherwise, it
should use WS/H2.
- When there's existing H2 connection established, if there wasn't
ENABLE_CONNECT_PROTOCOL in the initial SETTINGS from the server, use
WS/TCP, and WS/H2 otherwise.

Initially, I thought it might be fine to assume that there's existing H2
when WS attempt is made, but it's not always true, I guess.

----

Is it ok that we cannot announce tunneling capability for each protocol
separately? draft-hirano-httpbis-websocket-over-http2-01 allocated a
dedicated SETTINGS identifier for WebSockets
while draft-hirano-httpbis-websocket-over-http2-00 let each bit indicate
capability for each protocol.

In Patrick's proposal, currently we just determine tunneling yes/no and
then everything beyond is upper layer protocol's work.

I think this is fine if this tunneling is made completely independent from
the upper layer protocol.