Currently anonymous requests (Anon R) and credentialed requests (Cred R) go over different connections (Cs), even when the origin is the same. Cs that take Cred R can also become authenticated (Auth C). (In https://groups.google.com/d/topic/mozilla.dev.tech.network/glqron0mRko/discussion we did not discuss what currently happens with Cs that take Anon Rs and try to authenticate themselves. I suspect the Anon R that triggers it must fail in the NTLM case and the C must fail in the TLS client certificate case?) The proposed change to this model is that Anon and Cred Rs go over the same C as long as it's not an Auth C. If an Anon R triggers the server to negotiate NTLM, then fail the Anon R. If C has carried Anon Rs and the server tries to negotiate TLS client certificates, then fail C. An Auth C can continue to take any Cred Rs, but a new Anon R would create a new C. (Presumably any Cred Rs would continue to go over the Auth C as long as it's active. Don't think we discussed this.) HTTP/2 Cs cannot be authenticated to begin with and can therefore always share Anon and Cred Rs (though note that this is also a change from our current behavior).
+1 It feels like we could extend this to other origins under the same authority. Currently, if example.com includes <link rel="stylesheet" href="https://cdn.example.com/styles.css">, which references a font also on https://cdn.example.com, you end up with three connections. It'd be great to use one.
Yeah, if they share a certificate with the appropriate SAN entries that would fall out of OP.
+1 - this would resolve a lot of confusion around `<link rel=preconnect>` and H2 push for resources fetched with anonymous requests.
(In reply to Yoav Weiss from comment #3) > +1 - this would resolve a lot of confusion around `<link rel=preconnect>` > and H2 push for resources fetched with anonymous requests. How exactly?
(In reply to Honza Bambas (:mayhemer) from comment #4) > (In reply to Yoav Weiss from comment #3) > > +1 - this would resolve a lot of confusion around `<link rel=preconnect>` > > and H2 push for resources fetched with anonymous requests. > > How exactly? Preconnect hints have to include the `crossorigin` attribute for connections that will use the anonymous connection pool. So we're forcing users to be aware of that implementation detail and take it into account. H2 pushed resources are stored in a container linked to a specific H2 connection, so pushing resources that would use a separate connection (e.g. Fonts on a sharded domain) often results in wasted bandwidth.
I wrote a little about the issues in terms of H2 push https://jakearchibald.com/2017/h2-push-tougher-than-i-thought/#requests-without-credentials-use-a-separate-connection