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.
-P On Sun, May 7, 2017 at 2:36 PM, Christian Biesinger <[email protected]> wrote: > 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 <[email protected]> > 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 <[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 >> > _______________________________________________ dev-tech-network mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-network
