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

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

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

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.

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 <tyoshino@google.com>wrote:

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