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

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 (陈智昌)
<willchan@chromium.org>wrote:

> On Tue, Mar 4, 2014 at 9:07 AM, Mark Nottingham <mnot@mnot.net> wrote:
>
>>
>> On 4 Mar 2014, at 11:25 am, Roberto Peon <grmocg@gmail.com> 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.
>>
>
> 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,
>>
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>
>>
>