Currently, accessing data on commons via the canonical URI eventually ends up at index.php?action=raw:

• https://commons.wikimedia.org/data/main/Foo.map →
• https://commons.wikimedia.org/wiki/Special:PageData/main/Foo.map →
• https://commons.wikimedia.org/w/index.php?title=Foo.map&action=raw

Special:PageData adds an Access-Control-Allow-Origin: * header to its redirect, but there is no such header on the first redirect, nor on the final response, which means that in a cross-origin scenario (e. g. fetching the data via JavaScript on another website) the request is blocked. (Aside: if I understand correctly, Firefox doesn’t yet support CORS on redirects at all. See Bug 1346749.) To enhance availability of these data, there should be a way for other websites to dynamically access the data in a way where the response can be cached.

There is a workaround to this problem: use the Action API (which supports CORS), with action=query, prop=revisions, and rvprop=content (and selecting the pages with titles, pageids, or some generator, etc.), and extract the page content from response.query.pages.{pageId}.revisions[0]['*']. However, API responses are never cached, resulting in more work for the API servers as well as lots of unnecessary data transfer. Correction: the response is cached according to the maxage specified in the request; however, I’m not sure if this works if pages are edited or purged (as far as I can tell, the browser doesn’t validate its cached data), so it can be hard to choose the right maxage. (This workaround also requires that you parse and transform the canonical URI, which is ugly.)

As far as I understand, this will definitely require at least an Access-Control-Allow-Origin: * header on the /data/main, redirect, which can be added like this. After that, there are different options. We can make index.php send that header as well on any successful GET request to the Data: namespace, but this seems a bit risky. Alternatively, we could make Special:PageData redirect to something other than index.php?action=raw (which isn’t a very nice solution anyways), e. g. an endpoint of the REST API. The REST API already supports the endpoint /page/wikitext/{title}, but only for POST requests. We could add support for GET requests to it, or perhaps add another endpoint (after all, the content model isn’t actually wikitext).

See also the related issue T150290: add CORS to all redirects in chain from https://www.wikidata.org/entity/{Q...}, which also features a redirect chain with partial CORS support.