Tested same scenario in Firefox and it reused the connection for the CORS GET/POST after the OPTIONS request.

Maybe you're using the XHR with .withCredentials set to true. CORS preflight requests are sent with the credentials flag set to false as specified in the Fetch spec, while the actual request are not.

OTOH, Chromium has a feature named privacy mode with which enabled it uses separate socket pools for credentialed ones and non-credentialed ones.

This makes the CORS preflight and the actual request use different socket pools resulting in establishing separate sockets.

Ideally preflight and actual should be able to use the same socket. I'm not so familiar with the mode of the channel ID / token binding, but I guess at least reusing a socket used for the preflight for the actual should be fine though.

Adding rsleevi@, balfanz@.

Really adding them, and mkwst@

Pretty much this is WAI - and consistent with the https://fetch.spec.whatwg.org spec, AFAICT.

There's no requirement (or reasonable expectation) that it should reuse the socket.

https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html discusses persistent connections being the default expectation for any HTTP connection.

Why is this different for CORS OPTIONS->GET/POST HTTP requests?

The Fetch spec is the relevant specification - and notes connection groups and the security properties (as it applies to the Web Platform) that lead to distinct pools for the reuse of requests.

Setting aside that RFC2616 has been obsoleted (by RFC 7230 - 7235), it defines the transport profile, while it's up to specific applications to discuss the application profile. In the context of the Web Platform, the Fetch specification is the relevant application profile "for the web"

In particular, https://fetch.spec.whatwg.org/#connections applies

Thanks rsleevi@, apologies for the old spec.

We are indeed using .withCredentials set to true for the XHR request, so it sounds like tyoshino@'s comments are in line with the behavior.

That being said, it does hurt our client side performance as two HTTP connections need to be established to the same host. 

Is there a risk from re-using a TCP connection to the server for requests that have different credential flags? Is this a bug in the fetch spec that is not considering the performance implications of separate pools for connections that are made with and without credentials?

I can imagine that it is possible for a server to receive a request without credentials and use a weaker security model, and then apply similarly weak security model to the subsequent request that does include credentials because it used the same connection, but that would be a security issue with the server.

Thanks for your insights into the problem.

Marking this WontFix, as it's behaving as specified.

The distinction between the two pools is made for both privacy (e.g. first & third-party cookie blocking) and security (e.g. ambient authority, particularly with connection-level authentication) reasons.

The bug to star in the Fetch spec is https://github.com/whatwg/fetch/issues/341