Anne van Kesteren <ann...@annevk.nl> wrote: > Concerns raised by Monsur > https://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0260.html > and others before him are still valid. > > When you have an HTTP API on another origin you effectively get a huge > performance penalty. Even with caching of preflights, as each fetch is > likely to go to a distinct URL.
Definitely there is a huge performance penalty per-request when the preflight isn't cached. But: 1. Preflight is only necessary for a subset of CORS requests. Preflight is never done for GET or HEAD, and you can avoid preflight for POST requests by making your API accept data in a format that matches what HTML forms post. Therefore, we're only talking about PUT, DELETE, less common forms of POST, and other less commonly-used methods. 2. It seems very wasteful to design an API that requires multiple PUT/DELETE/POST requests to complete a transaction (I'm using the word "transaction" loosely here; I don't mean ACID, necessarily). A lot of people think that REST means that you should only change a resource by PUT/DELETE/POSTing to its URL, however that's a misunderstanding of what REST is really about. Regardless of CORS, it is a good idea to design APIs in such a way that every modification transaction can be done in one or as few requests as possible, and this can be done a way that is in line with RESTful design. This type of design is more-or-less required when you need ACID transactions anyway. 3. Often you can predict which resources need preflight. With HTTP/2 and SPDY, the server can use the server push mechanism to push preflight responses to the client before the client even sends them. Given #1, #2, and #3, I'm a little bit unsure how bad the performance problem really is, and how bad it will be going forward. It would be good to see a concrete example to get a better understanding of the issue. Cheers, Brian