Re: CORS performance

Anne van Kesteren <annevk@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

Received on Thursday, 19 February 2015 10:43:44 UTC