Inconsistent and missing CORS headers on plugin/theme API

[DavidAnderson]

The wordpress.org plugins/themes API is setting CORS headers on
responses to some calls, but not others... in such a way that even
exactly the same request, by a different route, will get different
results. (I'm writing a JavaScript/browser application that interacts
with the API, and hence needs the headers).

e.g. do a GET for
​https://api.wordpress.org/plugins/info/1.1/?action=plugin_information&request%5Bslug%5D=akismet

Result: a CORS header:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Jun 2016 11:55:43 GMT
Content-Type: application/json; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
X-Frame-Options: SAMEORIGIN

but, do a GET for
​https://api.wordpress.org/plugins/info/1.0/akismet.json instead, which
requests the same data in the same format, and you get these headers,
resulting in a XMLHttpRequest failure:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 07 Jun 2016 11:59:10 GMT
Content-Type: application/json
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN

Interestingly the Content-Type header varies also.

[obenland]

@dd32 is the missing Access-Control-Allow-Origin: * an oversight or on purpose, based on the different versions?

[dd32]

Replying to obenland:

@dd32 is the missing Access-Control-Allow-Origin: * an oversight or on purpose, based on the different versions?

No reason, they were just built at different times for different purposes. All WordPress.org API's are written primarily for the use-case at hand, they're intentionally not designed to cater to all audiences as they're not general-purpose APIs.

I don't see any harm in adding the extra CORS headers to the 1.0/*.json api.

[obenland]

Fixed in [dotorg13793].