From:  Patrick McManus <>
Date:  08 May 2017 02:54:32 Hong Kong Time

Re: Credentials and connection pools


hi :biesi!

Its a good point, but the hash also has some credential info in it for the
case of ntlm cause you also don't want to mix user a and user b when you
are doing conn based auth. Hopefully that wouldn't need to surface up at
whatwg/w3c level.


On Sun, May 7, 2017 at 2:36 PM, Christian Biesinger 

> Well some authentication mechanisms are per-connection, not per-request
> (such as NTLM). Just make sure that this does not get co-mingled with
> requests that are supposed to be anonymous.
> Christian
> On Sun, May 7, 2017 at 2:29 PM Patrick McManus 
> wrote:
>> 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 
>> 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