Currently SpdySessionPool::aliases_ only stores the single IP address that was used for each HTTP/2 connection.  IP-based pooling implemented in SpdySessionPool::FindAvailableSession requires that this IP be an element of the set of IPs the new host resolves to.

On the other hand, when Firefox opens an HTTP/2 connection, it stores all the IP addresses resulting from hostname resolution in nsHttpConnectionMgr::nsConnectionEntry::mCoalescingKeys, not only the single IP address that was used to open the connection.  Firefox pools by IP address whenever there is an overlap between the two sets.

To understand the motivation of more aggressive pooling, consider the case of a large pool of say 16 IP addresses that serve two different hostnames.  The goal would be to allow reusing any HTTP/2 connection to the first hostname for the second one.  Suppose, however, that DNS returns a random subset of only 4 IPs each time for either hostname.  With Chromium's current logic the probability of reusing the connection is 4/16 = 0.25.  With Firefox's implementation, it is 1 - C(12,4)/C(16,4) = 0.73.

Discussion with CDN engineers reveals that there are at least two potential issues.  One is that a single cert and IP range might serve multiple services, some of which can be IPv4-only while others might be IPv6 compatible.  Therefore it is desirable to restrict this logic to the same IP version.  (For example, if the first resolution returned some v4 and some v6 addresses and v6 was used to create the connection, then that connection should not be reused for a hostname that only resolves to v4 addresses.)

The other issue is that CDNs might want to restrict this kind of pooling because it can interfere, for example, with load balancing.  ORIGIN frame would enable them to do so.  Therefore this change should only be done once Chromium supports ORIGIN frame.