Code looks fine in itself however, this is only going to work for one endpoint no?

Maybe we could use a decorator to make this work with all the endpoints we want?

I've updated the PR.

This likely needs to be async

Did you see https://github.com/aio-libs/aiohttp-cors it looks like it may also do what we want. What do you think?

yes, I've had a look at it and it also can achieve the same. I wonder if it isn't overkill for our purposes

Since all the views on mdapi are susceptible of being cross origin called, why not go with a global postrequest implementation that add the headers to all the responses instead of a decorator that we'll forgot to add if we expand mdapi?

I don't think this'll be a big issue. Whoever is going to add a new endpoint will be looking at the existing ones anyway

I agree with @karsten that people will be looking at the existing endpoints, however @jlanda 's idea is simply safer.

aiohttp's middleware seems to be the way to do that:
https://docs.aiohttp.org/en/latest/web_advanced.html#middlewares

I've updated the PR and use aiohttp middleware now

It looks good, but something looks wrong about the commits. I see a commit from Clément and your commit seems to have both the removal of the previous attempt as well as the new one.

Maybe it needs a rebase against master?

s/GET1/GET

From https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Headers

The CORS-safelisted request headers, Accept, Accept-Language, Content-Language, Content-Type are always allowed and don't need to be listed by this header necessarily. However, note that additional restrictions apply with these headers which you circumvent by listing these headers in an Access-Control-Allow-Headers header as well.

So as I understand there is no need of this header

This is looking good!
Let's address @jlanda's and get this in :)

I've removed the typo and Access-Control-Allow-Headers

Thanks! :)