Investigate status of CORS

[danbri]

@RichardWallis can you investigate status of our CORS implementation?

I'm hearing we have issues:

Did you know schema.org does not support OPTIONS method in HTTP and do not CORS? You can’t read an ontology term from a script. Supporting CORS on GET isn't a thing as CORS requires the browser to send a OPTIONS first

[danbri]

hmm I guess this should be in the other repo, sorry!

[RichardWallis]

Addressed in sdopythonapp issue 6

Ready for test when a new version is uploaded to webschemas.org.

@danbri When it is, can you ask who you heard it from to try it out.

[danbri]

Ok, how does it look now?

[RichardWallis]

curl -i -L -X OPTIONS http://webschemas.org

Returns what looks to be the correct output:

HTTP/2 204 
content-type: text/html; charset=utf-8
cache-control: no-cache
access-control-allow-origin: *
access-control-allow-methods: GET, HEAD, OPTIONS
....

Also if request includes an Origin header its value is used in the Access-Control-Allow-Origin response:
curl -i -L -H "Origin: http://example.com" -X GET http://webschemas.org

Returns

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://example.com
Content-Type: text/html
...

[RubenVerborgh]

curl -i -L -X OPTIONS http://webschemas.org is missing

Access-Control-Allow-Headers: Accept, Accept-Language

or, at the very least just Accept.

The reason for this is that, even though Accept is safelisted (https://fetch.spec.whatwg.org/#no-cors-safelisted-request-header-name), it loses that status if its value contains more than 128 characters (https://fetch.spec.whatwg.org/#cors-safelisted-request-header). And 128 is not a lot for RDF-based clients if they start including all RDF variants in Accept. (Full discussion in whatwg/fetch#862)

[RichardWallis]

Fixes applied in sdopythonapp ( schemaorg/sdopythonapp#6 (comment) )
Will ship with next schemaorg release (v7.0)

[RichardWallis]

Apart from one outstanding issue comment All concerns addressed so closing.