- From: Yutaka Hirano <yhirano@google.com>
- Date: Mon, 17 Mar 2014 16:11:32 +0900
- To: Takeshi Yoshino <tyoshino@google.com>
- Cc: Roberto Peon <grmocg@gmail.com>, William Chan (陈智昌) <willchan@chromium.org>, Mark Nottingham <mnot@mnot.net>, Martin Thomson <martin.thomson@gmail.com>, Matthew Kerwin <matthew@kerwin.net.au>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CABihn6Eeea2THYdX3PxjTgAt0GFTNYEx5304p6JjrmLLnjrn=w@mail.gmail.com>
> > 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/ >>>> >>>> >>>> >>>> >>>> >>> >> >
Received on Monday, 17 March 2014 07:12:02 UTC