The history predates me, I presume it was a well intentioned privacy rule - but partitioning according to anon/non-anon is rather pointless- the peer can correlate by address or dns-cookies just as effectively if it wishes to.. and as you point out this partition is really painful - it has both performance implications and often leads to hard to explain outcomes. (fonts interacting with preconnect were a good pain poiint to highlight). I'd be happy to get rid of the separation and doing so in gecko would be trivial. (the anon flag is part of the hash key, it would just need to be removed.)
On Sun, May 7, 2017 at 2:07 AM, Anne van Kesteren <[email protected]> wrote: > As I understand things we pick connections to reuse based on an origin and > a credentials flag (set/unset). This got a little bit more complicated with > HTTP/2 as it's not just an origin A, but also any other "origin" entries in > A's certificate, but that's not what I'm after. > > What I'd like to understand is the history behind using credentials as a > key and what we can do to possibly change it. We now have some features > that don't send credentials by default (even same-origin), such as <script > type=module> and fetch(), and as a result you get two same-origin HTTP/2 > connections. This plays poorly with HTTP/2 push. > > A standards-related discussion on this is hosted here: > https://github.com/whatwg/fetch/issues/341. (Fetch also defines when > connections get reused (though it doesn't define the HTTP/2 certificate > bits yet).) > > (As an aside, having someone from the networking team watch whatwg/fetch > and give feedback would really help that work progress faster. > Alternatively, if you give me some GitHub IDs to ping when I get stuck that > could work too. Much appreciated.) > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network > > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
