Reducing the impact of preflight requests

For quick reference, a preflight request is required to be performed by a user agent implementing CORS when any of the following conditions are met:

• The method is something other than GET, POST or HEAD
• A header other than Accept, Accept-Language, Content-Language or Content-Type is set manually
• Content-Type has a value other than application/x-www-form-urlencoded, multipart/form-data, or text/plain

Since matrix uses Content-Type: application/json, all non-GET requests require a preflight, this means for example that sending any event to the server requires 2 requests, adding additional latency and a bit of overhead

Unfortunately there's no perfect solution to the problem, but here are some options:

Proxy requests through the same origin

This one shifts the work onto the client meaning nothing has to change spec wise, but has quite a few issues:

• Requires trusting the proxy to handle sensitive information (login details)
• Adds latency through indirection
• Adds another point of failure
• Not possible with static sites

Allow Content-Type: text/plain

Feels like a hack, but parsing plain text POST messages as if they were JSON would mean no preflight request. However this wouldn't help for the common path of sending messages to rooms which uses PUT

Improve preflight cacheability

Preflight requests can be optionally cached by the user agent indicated using the header Access-Control-Max-Age. However the cache is per URL not just the origin, meaning that any change in the path (which includes query parameters) warrants another preflight request

The large issue with this one is that it would require a breaking change to the API, with frequently changing parameters being placed in the JSON body or as HTTP headers

Websockets

Websockets have no such overhead once the connection is established, however whilst they do not require breaking API compatibility it's still a large spec addition

Start with the W3C CORS preflight and Access-Control-Max-Age references linked in the issue, then compare the proxy, content-type, cacheability, and WebSockets options. No repository file, test, or entry point is identified; the work is done only once the project agrees on a concrete, compatible API or specification change.