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

On Wed, Mar 5, 2014 at 6:18 AM, Roberto Peon <grmocg@gmail.com> wrote:

> 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.
>

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.


> 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.
>

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?


> (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.
>

Agreed


>  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/
>>>
>>>
>>>
>>>
>>>
>>
>