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

Presumably you opened the connection because you have requests to make for the origin in SNI; send those immediately.  Of course, you might have expected to coalesce based on history/certificate, and that's reasonable to attempt.  I think I'd mostly say that connections on which an ORIGIN frame hasn't been received aren't considered in the "proper subset" check.

-----Original Message-----
From: Martin Thomson [] 
Sent: Monday, September 25, 2017 2:45 PM
To: Mike Bishop <>
Cc: Bence Béky <>; Patrick McManus <>; HTTP Working Group <>; mnot <>; Erik Nygren <>
Subject: 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 frame).

Should we codify that advice?

Received on Monday, 25 September 2017 22:02:36 UTC