mkwst:  Is this just CORS / "privacy mode"?

Tested the same on mac 10.11.6 chrome version 54.0.2840.87 and canary - Observed that the same connection Id displayed for the domain assets and different for www

Please find the screenshot

Could you please upgrade to latest stable and see if issue still exists

Deleted: Screen Shot 2016-11-04 at 4.54.05 PM.png 1.3 MB

	Screen Shot 2016-11-04 at 4.54.05 PM.png 1.3 MB View Download

I just tried again on Win10 with Version 54.0.2840.87 m (64-bit), and I still had different Connection IDs for all fonts.
On macOS, I tried again with Version 54.0.2840.87 (64-bit): same results.
What would you need to reproduce?

Deleted: win10_54.0.2840.87.png 243 KB

	win10_54.0.2840.87.png 243 KB View Download

Deleted: macOS_54.0.2840.87.png 270 KB

	macOS_54.0.2840.87.png 270 KB View Download

Could you please provide us with an about:net-internals log?  It will at least let us check if the issue is privact mode sockets.  Instructions:  https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Note that the log has URLs (including query strings), PAC file path, and DNS config, but it removes cookies, HTTP auth data, and doesn't have post bodies (Though the lengths of all of those is included, or can be deduced from the data it contains)

Sure! Here you go.

By the way, if you need to check more things on this website, you can set a DNT header so you get only "local" scripts (ie. no social widgets, no tracking etc.) so as to avoid confusion.

Which, I suspect, is what might have happened in Comment 3 because I can see a different Connection ID for the fonts in "Screen Shot 2016-11-04 at 4.54.05 PM.png": ID 2213 for most assets while the fonts use ID 2482. There are other IDs for other domains, but they don't fall under this issue.

And I can confirm from the log that this is indeed privacy mode.  DO_NOT_SAVE_COOKIES | DO_NOT_SEND_AUTH_DATA | DO_NOT_SEND_COOKIES are set on the font requests, but not on the others, so they go to the socket pool that doesn't use credentials, and have to use their own socks.

So, should I do something on the website to change this behaviour, or will this be fixed in Chrome at some point?

Mkwst:  Is there an actual spec on which requests are credentialed, and which are not?  This stuff is completely opaque to the network stack.

mmenke@: Sorry for the delayed response. According to https://drafts.csswg.org/css-fonts/#font-fetching-requirements, we load fonts in "anonymous" mode, which does indeed set those flags on the font request. So far as I can tell, this is WAI, though I'm not sure the impact on connection coalescing is anticipated.

kenjibaheux@, can you triage this?

ksakamoto: any thoughts on this? Connection coalescing sounds better but not sure if this is allowed per the spec. Wondering what other browsers are doing in that regard.

Temporarily reverting to P3/Untriaged (scream if P1 was the right priority).

If auth is disallowed, we don't want to use a connection which may have been authed.  Same goes for cookies.  This is an inevitable and expected result of separating out "privacy mode" connections.

Pretty sure this is WontFix; as mmenke@ described, this is intentional behaviour and covered by https://fetch.spec.whatwg.org/

In particular, the https://fetch.spec.whatwg.org/#connections definition describes the pools as being associated by origin *and* credentials flag. As noted in Comment #10, the credentials flag being set to "anonymous" is distinct pool than the credentials flag being set (e.g. to "same-origin" or 'true'), so WAI.

The about:net-internals log was indeed done with a guest session for simplicity, and in that case I completely understand what you mean. However, all the screenshots I provided were done with actual user sessions (and I suppose comment 3 too). Those connections shouldn't be anonymous.

'anonymous' during our discussions refers to the CORS mode, not to Guest Sessions, and is described within the Fetch spec. That is, it's a fetch without the credentials flag set (excludes credentials), which includes cookies. For such requests, Chrome intentionally (and as specified in Fetch spec) uses a distinct connection.

You can find ample discussion of these matters in the Fetch issue tracker, related to the tension between performance and privacy/security. This applies to cookies, HTTP connection-based authentication mechanisms (NTLM/Kerberos/Negotiate), and TLS client certificates.

Ok thanks the clarification. I'll ask upstream if the impact on connection coalescing was anticipated, then.