CORS support on servers we depend on

[rybesh]

In modern web browsers, making requests from JavaScript (JS) to URLs with domains that differ from the one where the JavaScript originated is forbidden by default.

Servers that wish to allow JS requests from other domains can indicate this by setting an Access-Control-Allow-Origin header, e.g.

Access-Control-Allow-Origin: *

to allow JS requests from any domain.

Since JS applications working with linked data URLs need to be able to make GET requests to those URLs, in order to discover the resources to which they point, then it makes sense for both URL resolvers and linked data servers to set this header.

In order to ensure that JS on arbitrary domains can only read and not write to URL resolvers and linked data servers, it may also make sense to only allow GET requests by setting an Access-Control-Allow-Methods header, e.g.:

Access-Control-Allow-Methods: GET

Since a 302 Redirect (or other redirect) response is useless without the Location header, and browsers by default do not expose the Location header to JS, it also makes sense for URL resolvers to expose that header by setting an Access-Control-Expose-Headers header, e.g.:

Access-Control-Expose-Headers: Location

By setting these headers, URLs of linked data publishers and resolvers become usable from JS running in browsers, without compromising the security of their servers.

Unfortunately, more than six years after Cross-Origin Resource Sharing (CORS) became a W3C Recommendation, support for these CORS headers among major scholarly data publishers and resolvers is still poor.

[rybesh]

• [ ] ORCID orcid.org does not set CORS headers: test pub.orcid.org does not set CORS headers: test pub.orcid.org/v3.0/ does set CORS headers: test
• [X] DOI supports CORS doi.org does set CORS headers if an Accept header is set : test dx.doi.org does set CORS headers if an Accept header is set : test doi.org/api/handles/ does set CORS headers test data.crossref.org does set CORS headers but will fail with 406 Not Acceptable unless an Accept header is set to one of the content types that Crossref supports: test (Note also that not all DOIs are Crossref DOIs, so we might want to consider using doi.org rather than data.crossref.org to resolve DOIs.)
• [ ] Worldcat www.worldcat.org does not set CORS headers test experiment.worldcat.org does set CORS headers, but only on HTTP requests and not HTTPS requests, which is useless: test http / test https
• [X] N2T supports CORS n2t.net does set CORS headers test

[gbilder]

Hello. Perhaps try this test for dx.doi.org/doi.org?

Or with curl:

curl -L -I 'Origin: http://www.example.com' -H 'Accept:application/vnd.citationstyles.csl+json' http://doi.org/10.1155/2013/564864

[rybesh]

Thanks @gbilder! I've updated the list to reflect that [dx.]doi.org do correctly support CORS.