Re: [whatwg/fetch] Clarification on CORS preflight fetches for TLS client certificates (#869)

I have been reading through this thread, and wanted to verify my understanding of everything is correct. As things stand it seems like Client Certificate + CORS + HTTP/2 is not a valid combination of things to use. Is that right?

My understanding is that with CORS and Client Certificate the `OPTIONS` request can / should be done without the certificate based on the spec. And if you are using HTTP/2 the connection is not renegotiated after the `OPTIONS` request is complete. So when you get to an actual request, like a `POST`, it fails to validate the certificate since none was provided. This seems to be quite problematic as far as the specs go.

I certainly would like to take advantage of HTTP/2 benefits, but I have to use Client Certificates and CORS, and it doesn't work as I would have expected. I have experienced plenty of issues with Client Certificates before and the application works fine in both Chrome and Firefox via HTTP/1.1, but things stopped working in Firefox when I turned on HTTP/2. It took finding this thread to understand what was happening. 

Even if I wanted to, I do not have control of browsers settings on every client machine to set `network.cors_preflight.allow_client_cert` on them. So its not really a viable option.

I am also trying to understand specifically with `OPTIONS` requests. Why is it that the spec requires me (the server) to respond to the request before they have mutually authenticated? That means I have to return information about the route to an unauthenticated client. That seems less than ideal.



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