Consider `cors` middleware

[grabbou]

Would be handy to have it out-of-the-box with api-defaults config. What you think?

[venantius]

This issue is now a few years old and it seems to me the space has continued to move in this direction. If your API isn't being served from the same domain, CORS middleware is now a requirement for production deployment. I know there are existing solutions out there for CORS middleware but I think having a solution in Ring would still be a good idea (and candidly, I always feel safer using middleware from ring over a third party). @weavejester, thoughts?

[weavejester]

I don't think that would be a bad idea. Support for it is probably more stable now than it was. Of course, Ring-Defaults just provides defaults for existing Ring libraries, so first we'd need to build some appropriate middleware - either in Ring-Headers or a new Ring-CORS library. I'm leaning toward the latter.

[venantius]

I would suggest a merge of https://github.com/r0man/ring-cors. It's what I've used in the past -
it has a sane interface and covers the basics. Your call on where it should ultimately sit. Personally, I think since it's basically just string manipulation and has no external dependencies the bloat is small enough that it doesn't belong in a standalone lib (I was originally thinking ring-core).

[weavejester]

Unfortunately, licensing differences make ring-cors unusable for this purpose. It shouldn't be too hard to recreate something like it from scratch, however.

The resulting library definitely shouldn't be in Ring-Core. Ring-Headers is a possibility.