Adding server checks for the ability to retrieve the ontology from a web browser

Services and Applications DBpedia Archivo
#1

Hello,

This is a suggestion for the 5th star extension.

I just failed to load our own vocabulary http://open-services.net/ns/core# from a JS RDF client due to the CORS policy. I realised that I will hit the same issue with FOAF and others and ended up writing an RDF document proxy https://github.com/berezovskyi/corsherdf. As you understand, proxy is a kludge that always hints at a problem and right now it is that most Linked Data and Semantic Web servers are configured in a way that prevents RDF resources to be used in any kind of “hypermedia” form (where a client dereferences resources itsefl).

Proposed qualifying criteria for the 5th star:

  • an ontology allows a CORS request when a preflight request was sent from at least two different domains.
  • a CORS response allows to use a Content-Type header to preform content-negotiation in the browser RDF client.

Best regards,
Andrew

1 Like
#2

Hi,

this is a great idea, I opened a issue in github for that topic: https://github.com/dbpedia/archivo/issues/8

Best regards,
Denis

#3

Hi @berezovskyi maybe it makes sense to combine this also with an HTTPS check and call it WebApp feature star/ badge ? Wdyt?

@yum-yab I added an issue to enable CORS for our fetch API.

#4

Hello Johannes,

That’s a great idea to extend dereferenceability checks and bundle them together. I am not sure if HTTPS check is necesary in relation to CORS for the browser-side dereferenceability (avoid mixed content warnings/errors maybe?) check but I would be interested to use it in the server-side dereferenceability check. I often found myself unable to fetch RDF resources without configuring my server HTTP client in some way:

  • TLS cert issues (before https://www.infoq.com/news/2020/04/tls-alpn-java8/ it was not possible to connect to a server with a LetsEncrypt cert using Java 8)
  • self-signed TLS certs
  • redirects with non-common codes (e.g. Spring default HTTP client, Netty, does not seem to like 303 redirects that dcterms seems to serve as one of their many redirects)
  • error responses with text/html and 200 OK code
  • non-standard date formats in cookies (requires this setting, for example)

It may be interesting to set up a few “reference” clients in Java, Python, Ruby, JS/Node to check if a client with a “regular” configuration can fetch a response from the server. Ideal outcome: Apache HttpClient in Java, requests lib in Python, faraday gem in Ruby, axios client in Node should all require no special configuration (except maybe allowing redirects) to fetch an ontology.

But I guess that’s a different proposal altogether.

–Andrew