Re: Working Group Last Call The ORIGIN HTTP/2 Frame

On Tue, Sep 26, 2017 at 2:51 AM, Mike Bishop
<> 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

Should we codify that advice?

Received on Monday, 25 September 2017 21:44:58 UTC