Subject: Re: HTTP/2, "h2t" and protocol identifiers in general

From: Matthew Kerwin <[email-masked]>
Date: Sat, 1 Mar 2014 18:58:02 +1000

On 1 March 2014 15:19, Amos Jeffries <[email-masked]> wrote:

> On 1/03/2014 3:25 p.m., Matthew Kerwin wrote:
> > On 1 March 2014 11:57, Amos Jeffries wrote:
> >
> >> On 1/03/2014 5:09 a.m., Mark Nottingham wrote:
> >>>
> >>> I'd be OK with "h2" for TLS and something like "h2p" (for "plaintext").
> >>
> >>
> >> FWIW: I prefer the orginal proposal where the 't' signified the
> >> injection of TLS layer between HTTP/2 and TCP.
> >>
> >>
> > And my two cents, because I love painting sheds: I prefer 'h2s' for
> HTTP/2
> > over TLS, for its symmetry with http/https.
> >
>
> I thought about suggesting that, but we are actually wanting to *detach*
> the symmetry.
>
>  => h2t in the proxy cases TLS without meaning HTTPS specifically.
>
>
I suppose so. In that case, does the token have to be quite so short? I
know there was this discussion: <
http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0941.html> but
it seems using a single letter after "h2" is a tiny bit of an issue. A
token that could be misinterpreted by a hurried implementer will eventually
cause someone some grief.

Here are my suggestions, in order of preference, and then I'll stop arguing
about paint colour (even though it matches my level of expertise
wonderfully):

1. "h2tls" and "h2tcp" -- these aren't protocol-stack-based identifiers, we
just avoid a default and explicitly differentiate between TLS and just-TCP.
2. "h2" for TCP+HTTP and "h2tls" for TLS -- because HTTP/2 makes no claims
about its transport (and TCP is an internet default), while TLS is an
explicit variation.
3. "h2" for TLS and "h2tcp" for just-TCP -- because TLS is likely going to
be the most common use-case, so it could be a justifiable default.
4. "h2" for TLS and "h2c" for "HTTP/2 in cleartext", in line with @mnot's
earlier suggestion.

-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/

---

From: Roberto Peon <[email-masked]>
Date: Mon, 3 Mar 2014 01:43:50 -0800

I'm concerned that, given the way this discussion has been heading, we may
see a combinatorial explosion of ALPN IDs.
I've opened: https://github.com/http2/http2-spec/issues/422 as a result.
-=R

On Sat, Mar 1, 2014 at 12:58 AM, Matthew Kerwin <[email-masked]>wrote:

> http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0941.html>
> but it seems using a single letter after "h2" is a tiny bit of an issue. A
> Here are my suggestions, in order of preference, and then I'll stop
> arguing about paint colour (even though it matches my level of expertise
> wonderfully):
>
> 1. "h2tls" and "h2tcp" -- these aren't protocol-stack-based identifiers,
> we just avoid a default and explicitly differentiate between TLS and
> just-TCP.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Mar 2014 01:49:45 -0800

> I've opened: https://github.com/http2/http2-spec/issues/422 as a result.

I really don't see how you can reach that conclusion.  I guess that we
have a different understanding of what an ALPN token is supposed to
mean.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 3 Mar 2014 01:55:00 -0800

It has two classes of meaning, depending on where/how it is presented.

In one case it represents a stack of protocols.
In another case, it cannot represent that...

-=R

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Mar 2014 02:23:50 -0800

> In another case, it cannot represent that...

In what other case?

---

From: Roberto Peon <[email-masked]>
Date: Mon, 3 Mar 2014 02:30:35 -0800

When using ALPN tokens within the actual ALPN extension, specifying TLS,
TCP, etc. (or the lack of same) is useless at best.
Such, however, makes sense over dns, alt-service, alt-protocol, etc.

-=R

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Mar 2014 02:37:21 -0800

> Such, however, makes sense over dns, alt-service, alt-protocol, etc.

Right, but I would expect that you simply never send the
h2{c|tcp|plain} label in ALPN itself.

---

From: Roberto Peon <[email-masked]>
Date: Mon, 3 Mar 2014 02:59:59 -0800

We currently have a number of application-layer applications that we might
want to use, a number of protocols, a number of transports, and at least
two levels of 'security'.
{http,ws}/{tls/,}{tcp, udp}/ip

This is already 8 combinations. If we add another application-layer
protocol and another transport (sctp for instance), we're up to 18...

If goodness forbid, we find some need to specify schemes, this becomes more
ludicrous.
If we're even thinking about going any length down this road, then we need
to at least reserve the capability to do something reasonable about this.

-=R

---

From: Martin Thomson <[email-masked]>
Date: Mon, 3 Mar 2014 03:10:05 -0800

On 3 March 2014 02:59, Roberto Peon <[email-masked]> wrote:
> want to use, a number of protocols, a number of transports, and at least two
> levels of 'security'.

Aside from noting that the UDP option is far from being a reality, that's right.

And that seems manageable to me.

---

From: Matthew Kerwin <[email-masked]>
Date: Tue, 4 Mar 2014 05:58:30 +1000

On Mar 3, 2014 9:00 PM, "Roberto Peon" <[email-masked]> wrote:
>
> We currently have a number of application-layer applications that we
might want to use, a number of protocols, a number of transports, and at
least two levels of 'security'.
>
> If goodness forbid, we find some need to specify schemes, this becomes
more ludicrous.
> If we're even thinking about going any length down this road, then we
need to at least reserve the capability to do something reasonable about
this.

The goal of Alt-Svc as I understand it is to specify different ways to
access an identical service. These could be as simple as a different ip
address for a multi-interface server, to a completely different protocol
stack (eg. http1/tcp/ip4 -> h2/tls/tcp/ip6). It's important to note that
http/1.1 and h2 are interchangeable only at the transport level, because
the higher semantic parts (the "scheme", as we seem to be calling it) are
the same. Changing the scheme means changing the way we can interact with a
resource means changing the service.

The current proposal for describing an Alt-Svc protocol stack seems to be
something like:

1. ip version (implied by the value of the address given)
1b. ip address
2. "tcp"
2b. tcp port
3. everything else, using ALPN

We can eliminate tcp-vs.-udp(-vs.whatever) from the ALPN token by adding an
explicit field to Alt-Svc to differentiate that layer. This means another
registry of protocol identifiers, which might be beyond this wg, but there
it is.

I think we're safe with ip(4/6)... Unless anyone wants to suggest we allow
IPX or RIP there? Maybe IPsec?

If "everything else" is leveraging ALPN's existing identifier registry,
that registry had better be able to handle all the options we require. So
far those seem to be: http1(+TLS?), http2, http2+TLS, websockets, and
ws+TLS.

Five doesn't seem so bad. Incidentally, if TCP goes away, I'm altering my
preferences for tokens to:

1. 'h2' and 'h2tls', or
2. 'h2c' (=cleartext) and 'h2'

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Mar 2014 11:18:25 +0000

> {http,ws}/{tls/,}{tcp, udp}/ip

Maybe, maybe not; only if ws actually needs a different protocol identifier would the first segment be necessary.

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

---

From: Roberto Peon <[email-masked]>
Date: Tue, 4 Mar 2014 03:25:19 -0800

How does one determine WS usnig HTTP2/TLS/TCP as compared to WS over
TLS/TCP?

On Tue, Mar 4, 2014 at 3:18 AM, Mark Nottingham <[email-masked]> wrote:

> Maybe, maybe not; only if ws actually needs a different protocol
> identifier would the first segment be necessary.
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Mar 2014 17:07:53 +0000

On 4 Mar 2014, at 11:25 am, Roberto Peon <[email-masked]> wrote:

> How does one determine WS usnig HTTP2/TLS/TCP as compared to WS over TLS/TCP?

We haven’t discussed much yet, but there are two (not necessarily exclusive) proposals:

- You try; if the other end doesn’t support WS, it refuses with an error code.

- You discover what schemes the server supports using a SETTINGS.

This assumes you already have an HTTP/2 connection open to the server; if you don’t, you have to figure out what to do, but I *think* that’s a WS/1 problem, not ours.

Cheers,

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 4 Mar 2014 10:29:17 -0800

On Tue, Mar 4, 2014 at 9:07 AM, Mark Nottingham <[email-masked]> wrote:

> We haven't discussed much yet, but there are two (not necessarily
> exclusive) proposals:
>
> - You try; if the other end doesn't support WS, it refuses with an error
> code.
>

I just want to point out that both of these approaches requires an extra
roundtrip in the TLS-ALPN HTTP/2 establishment case. Which is unfortunate
and might lead clients to race more connections.

> This assumes you already have an HTTP/2 connection open to the server; if
> you don't, you have to figure out what to do, but I *think* that's a WS/1
> problem, not ours.
>
> Cheers,
>
>
> --

---

From: Roberto Peon <[email-masked]>
Date: Tue, 4 Mar 2014 13:18:19 -0800

Lets say a browser supports WS over HTTP2.
In that case, I agree that seeing h2, and creating a stream with ws (which
the server decides to not reject) can work.
However, SETTINGS isn't currently flexible enough to say something about
supported protocols given that SETTINGS cannot be upgraded without a
protocol rev.
The other issue is that there is no positive acknowledgement that the WS
stream (or scheme) is accepted unless payload is sent (window-update can be
taken for ack/acceptance), which implies the client must use timeouts to
wait for a RST, which is suboptimal.
(There are obvious solutions to some of these problems, e.g. a
WINDOW_UPDATE of zero after accepting headers, defining settings or some
equivalent which allows the server to state what it accepts, or setting up
ALPN in such a way that the client already knows as part of the TLS
handshake).

And then there is the case where the browser does not support WS over
HTTP2, but does support WS over TLS (i.e. WS or WSS).
There is no token for this right now, and if there is it must not conflict
with any token that declares WS support over HTTP2.

Separate from how to do WS, but related:
The worry about structured ALPN tokens was about future proofing this kind
of thing for whatever other protocols get carried (and I know in our case
we're thinking about at least two other application-layer protocols, and
perhaps another transport).
(ALPN as currently defined does not preclude doing this-- the TLS layer
does not currently place semantic restrictions on the data negotiated in
the handshake
-=R

On Tue, Mar 4, 2014 at 10:29 AM, William Chan (陈智昌)
<[email-masked]>wrote:

>> you don’t, you have to figure out what to do, but I *think* that’s a WS/1
>> problem, not ours.
>>
>> Cheers,
>>
>>
>> --

---

From: Takeshi Yoshino <[email-masked]>
Date: Mon, 10 Mar 2014 17:37:53 +0900

> supported protocols given that SETTINGS cannot be upgraded without a

How about using ALTSVC or similar to advertise supported protocols?
- introduce a new parameter SETTINGS_PREFACE_ALTSVC_COUNT to the SETTINGS
frame. if just ws, value=1
- a server MUST send ALTSVC frames of the count asap after the preface
SETTINGS frame, if just ws, one frame
- a client MUST wait until it receives the specified number of ALTSVC
frames to be received before creating a stream

As Will said, the ALTSVCs comes later than 2RTT from ClientHello (and then
we need to re-establish non-h2 TLS for RFC6455/TLS/TCP), using structured
ALPN to announce WS/h2 capability is preferred. I.e. a client lists h2ws
(or something else indicating ws/h2 support is mandatory) and wss
(RFC6455/h2) in its ClientHello.

> wait for a RST, which is suboptimal.

I don't quite understand what you're talking about here. Do you mean that
we need HTTP/2 level acceptance in addition to WebSocket level successful
handshake response as a HEADERS frame? Or rather thinking about non-WS
protocol that doesn't involve handshake response?

> with any token that declares WS support over HTTP2.

Agreed

> On Tue, Mar 4, 2014 at 10:29 AM, William Chan (陈智昌) <[email-masked]
> > wrote:
>
>>> This assumes you already have an HTTP/2 connection open to the server;
>>> if you don’t, you have to figure out what to do, but I *think* that’s a
>>> WS/1 problem, not ours.
>>>
>>> Cheers,
>>>
>>>
>>> --

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 17 Mar 2014 16:11:32 +0900

> frames to be received before creating a stream

It is nice, we will have more flexibility than SETTINGS without introducing
significant latency.

> - You discover what schemes the server supports using a SETTINGS.

At a past hybi discussion we thought that the try and error impacts the
connection establishment time and hence we are seeking a way to detect the
server capability, which is (ALPN and (SETTINGS_SUPPORTED_SCHEMES or
(SETTINGS_PREFACE_ALTSVC_COUNT and ALTSVC))) currently.

Thanks,

On Mon, Mar 10, 2014 at 5:37 PM, Takeshi Yoshino <[email-masked]>wrote:

>> In that case, I agree that seeing h2, and creating a stream with ws
>> (which the server decides to not reject) can work.
>> There is no token for this right now, and if there is it must not
>> conflict with any token that declares WS support over HTTP2.
>>
>
> Agreed
>
>
>> The worry about structured ALPN tokens was about future proofing this
>> kind of thing for whatever other protocols get carried (and I know in our
>> case we're thinking about at least two other application-layer protocols,
>> and perhaps another transport).
>> On Tue, Mar 4, 2014 at 10:29 AM, William Chan (陈智昌) <
>> [email-masked]> wrote:
>>

---

From: Yutaka Hirano <[email-masked]>
Date: Mon, 17 Mar 2014 16:14:29 +0900

> and might lead clients to race more connections.
Yes, that's why we are proposing ALPN identifiers for WebSocket over
HTTP2 used in ALPN in addition to SETTINGS (or ALTSVC).

Thanks,