Closed dlongley closed 2 years ago
Hi @dlongley - I assume this is an issue with the config of the w3.org server? (not the ODRL json file)
Hi @dlongley - I've created an example: a web page with a link to the ODRL Jsonld file at https://test1.newsit.biz/fortesting/cross-access-odrl-jsonld.html
Clicking on "this link" of this page loads the Jsonld file - and the headers of the http request recorded by my Chrome Windows desktop browser don't include an origin
header and a wildcard is the value of the access-control-allow-origin
header in the http response.
I also tested setting the origin
header of the "this link" request to https://test1.newsit.biz
: in this case https://test1.newsit.biz
is applied as value of the access-control-allow-origin
header in the reply and cache-control
is max-age=21600
Then I uploaded the same HTML file to another server of my domain: https://data.newsit.biz/fortesting/cross-access-odrl-jsonld.html
... and I set the origin header to https://data.newsit.biz
: clicking on "this link" delivered the odrl.jsonld without further ado.
It looks like the cached odrl.jsonld file was ignored or overwritten - or the cache does not remember the origin of the request + response filling this cache.
@riannella,
Hi @dlongley - I assume this is an issue with the config of the w3.org server? (not the ODRL json file)
Yes, there's no issue with the context itself that I'm aware of. It seems to be a w3 server configuration issue that appears to be specific to the ODRL file, as running the same curl command to fetch, e.g., the credentials v1 context does not create the same issue:
curl -I -H "origin: https://test.example" https://www.w3.org/2018/credentials/v1
Yields the header:
access-control-allow-origin: *
@nitmws,
You must do a cross-domain request to load the ODRL context to trigger this error. Clicking a link will load the context from the same origin.
If you visit the first page you created:
https://test1.newsit.biz/fortesting/cross-access-odrl-jsonld.html
And run this in the JS console:
await fetch('https://www.w3.org/ns/odrl.jsonld')
It will likely succeed. Then visit the second page you created: https://data.newsit.biz/fortesting/cross-access-odrl-jsonld.html
And run the same in the console:
await fetch('https://www.w3.org/ns/odrl.jsonld')
This will now fail (if the first failed then that means you fetched the ODRL context using CORS recently somewhere else, like the JSON-LD playground). This also means that if you clear your cache and you reverse the order of the steps above (going to the second link first), then the first link will now fail to load the ODRL context due to a CORS error.
If you run this command on the site where the ODRL context fails to load due to a CORS error:
await fetch('https://www.w3.org/ns/odrl.jsonld', {cache: 'reload'})
You can reload the cache and successfully load it. It is clear that the browser is following the server's directives to cache the cross-domain response returned for 21600 seconds -- but the server sets access-control-allow-origin: <origin>
causing no other sites to be able to load the context via a cross-domain request until the cache expires.
@dlongley I've run your sequence of tests (now with MS Edge as Chrome's cache holds too much) and get the same error from the context of the https://data.newsit.biz site.
And this fetch
await fetch('https://www.w3.org/ns/odrl.jsonld', {cache: 'reload'})
works too.
@riannella I suggest to share this as a hint in the Implementation Best Practices as many examples set the @context with this file.
And it makes sense to let W3C know about that as this is not the only reference file on the w3.org server.
I will inform W3C sys support team
Thank you all for the bug report. There was indeed an issue with the module setting the CORS headers. This should now be fixed.
I can confirm that the fix works for me. Thanks! I'm closing the issue since I opened it and have confirmed it to be working for me now -- but if that's not your policy here and you need some other process, please feel free to re-open and do what you must.
If you run:
The server will rewrite the
access-control-allow-origin
header to use the passedorigin
value and tell the client to cache it for 21600 seconds. This means that the same browser trying to hit that URL over CORS from any other site will use the cached value and fail. The remedy is for the server to stop using the sentorigin
value and just use*
... or to include avary: origin
header so the client knows to use a different cached value based on theorigin
value sent in the request. Either fix should address the problem.