- From: Patrick McManus <mcmanus@ducksong.com>
- Date: Wed, 22 Nov 2017 23:45:22 +0000 (UTC)
- To: Bence Béky <bnc@chromium.org>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAOdDvNqq0eoTLS5ysfvtA+ZKoFV9q53s5ZOLC6g4sXJh1Ni1MQ@mail.gmail.com>
On Wed, Nov 22, 2017 at 8:58 PM, Bence Béky <bnc@chromium.org> wrote: > > > Since there is no requirement for the server to wait for settings ACK > before accepting Websockets requests, there should be no harm in the > client sending such a request right after sending its initial SETTINGS > on a freshly opened h2 connection. If the server supports Websockets, > the request will go through. If the server does not, then it will > reset the frame because of the undefined pseudo-header. The earlier > the client sends the request, the better latency we get. The earlier > the client gets a failure, the better latency we get for the > retry-over-h1 case. Am I missing something here? > > the opt-in settings is there to allow non-7540 compatible behavior. otherwise we wouldn't need it at all. a server that didn't opt-in to this extension must issue a protocol error upon receipt of the unknown pseudo header. So a client better not send it :) similarly a CONNECT with :scheme and :path elements must generate a protocol error on a server that didn't opt-in because they are explicitly disallowed by 7540 (in the absence of the extension). an alternative design with a new method and the protocol field stuffed somewhere else has end-to-end problems because there is no equivalent of "Connection" in h2 and also practical problems with any non-CONNECT method that has a fully bidi stream behavior (as opposed to request before response) in that kind of scenario. opt-in is annoying, but in this case I don't think its a big deal to move the ball forward - especially as you say the no-connection case is not expected to be all that common. > Or if this behavior is not desirable, then instead just default to h1 > every time there is no open h2 connection with Websockets support to > the server. As Andy mentioned, most of the cases we expect a warm > connection when a script requests a Websocket anyway. We can gather > some data about this and try to be clever later. > > Bence > >
Received on Wednesday, 22 November 2017 23:45:46 UTC