Re: [whatwg/fetch] Allow connection reuse for request without credentials when TLS client auth is not in use (#341)

There are some subtleties here to be careful around. It is possible for a connection to start life without requesting TLS client auth, and then after an HTTP request, suddenly request it. At that point, the connection has to choose which side of the divide it lives on. Should still be doable, but something to be wary of.

Now, in Chromium, we already just tear down the connection in that case and start it over from scratch (it's easier and this case is not a priority for optimizations), so we'd actually have an easier time with this, but I doubt everyone does this. (Though Chromium also has a long-standing bug where we do TLS client auth with uncredentialed requests anyway. No one's prioritized fixing that sadly. 😞)

But this also demonstrates that the exact implementation and behavior will vary a bit based on how the rest of the browser's net stack works. For example, we set a connection's client certificate disposition (send this cert, send no cert, tear down connection and ask) when the connection is first created. If the connection never sends CertificateRequest, this field ends up being a no-op. Probably the simplest implementation for Chromium would be to partition based on this disposition and not whether a CertificateRequest _actually_ happened, as the latter would cause a connection to move buckets over its lifetime.

And then if draft-ietf-httpbis-http2-secondary-certs ever happens, that'll add another dimension to the mix. But hopefully any HTTP-layer thing we do can be controlled on a per-request basis (the `USE_CERTIFICATE` frame in that draft) and we don't need to rely on connection partitioning to do it.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/fetch/issues/341#issuecomment-2135517752
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/fetch/issues/341/2135517752@github.com>