Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Allow some sharing of connections with different anonymous attributes

NEW
Unassigned

Status

()

Core
Networking
2 months ago
2 months ago

People

(Reporter: annevk, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-backlog])

(Reporter)

Description

2 months ago
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).

Comment 1

2 months ago
+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.
(Reporter)

Comment 2

2 months ago
Yeah, if they share a certificate with the appropriate SAN entries that would fall out of OP.

Comment 3

2 months ago
+1 - this would resolve a lot of confusion around `<link rel=preconnect>` and H2 push for resources fetched with anonymous requests.
Whiteboard: [necko-backlog]
Summary: Change the way we allocate connections → Allow some sharing of connections with different anonymous attributes
(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?

Comment 5

2 months ago
(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.

Comment 6

2 months ago
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
You need to log in before you can comment on or make changes to this bug.