Reducing the impact of preflight requests

[Alexendoo]

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

[richvdh]

Thanks for the suggestions.

It's worth noting that since the the authorization has moved into the headers (matrix-org/matrix-js-sdk#478), the situation has got worse in that all requests now get preflighted, which I suggest means that

Proxy requests through the same origin:

Unfortunately requiring a server-side component for things like riot-web, and giving the matrix access-token to whoever is hosting your web client, are non starters for us.

Allow Content-Type: text/plain

As you say, this is a hack. I think it also won't help due to the authorization headers.

Improve preflight cacheability

This might help reduce the number of preflight requests, though I suspect it won't give a useful reduction without moving lots of things from path/query params into request bodies.

Websockets

This might be the most practical solution. I've opened https://github.com/matrix-org/matrix-doc/issues/1148 to track this.