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
On Sun, May 7, 2017 at 2:07 AM, Anne van Kesteren 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