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

> 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.

The intent of the spec is that `OPTIONS` is a *public* protocol to query the server about supporting modern standards (CORS). As such, the server must be willing to declare support for modern standards without requiring authentication of any kind (client certs or otherwise).

Using `OPTIONS` for this is a workaround for the historical mess we currently have.

And the `OPTIONS` workaround unfortunately necessitates making two separate connections when you use HTTP/2 because client certs are on so low level feature in the stack.

It currently appears that both Chrome and Firefox are finally going to align with the spec so if you maintain a server and want to use CORS, you must be prepared to only have optional transport level client certs.

Yes, it's painful but it is considered the most secure way to proceed given the historical mess we currently have.

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

Message ID: <whatwg/fetch/issues/869/2162328018@github.com>