- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 26 Sep 2017 07:44:35 +1000
- To: Mike Bishop <Michael.Bishop@microsoft.com>
- Cc: Bence Béky <bnc@chromium.org>, Patrick McManus <pmcmanus@mozilla.com>, HTTP Working Group <ietf-http-wg@w3.org>, mnot <mnot@mnot.net>, Erik Nygren <erik@nygren.org>
On Tue, Sep 26, 2017 at 2:51 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote: > You do run into a potential loop with that, interestingly. If the uninitialized state is the set of origins in the certificate, but the server has used ORIGIN to reduce the number of origins for which it will use this connection, then a connection on which you've received an ORIGIN frame would always be a proper subset of a connection on which you haven't (yet, presumably). This could lead to some interesting behaviors for clients which open multiple connections in parallel for various purposes, if done naively. Right, there is a race. Between the time that the handshake completes and the time that ORIGIN is received, the connection could be marked as usable for a set of origins. A client might decide at that point to abandon connection attempts to those origins, or to start using the connection for requests to those origins. Either action results in delays as connections have to be re-established or requests retried. Clients might avoid this by waiting for the first response on a connection before coalescing (on the principle that ORIGIN is always sent before the first HEADERS frame). Should we codify that advice?
Received on Monday, 25 September 2017 21:44:58 UTC