Schema not reachable via $id

[miko007]

The $id url of any schema is unreachable at the moment. Opening https://schema.spaceapi.io/13.json gives a ERR_SSL_PROTOCOL_ERROR, possibly because you redirect http to https, but the server does not speak SSL on this vhost.

[dbrgn]

I don't think the $id needs to be reachable, or should it? My understanding is that domains / URLs are just used for namespacing.

[miko007]

@dbrgn as is just consulted the standard on that matter, you seem to be right. it says:

Note that this URI is an identifier and not necessarily a network locator. In the case of a network-addressable URL, a schema need not be downloadable from its canonical URI.

which i find very confusing. So you can pull in other schemas via "$ref" : "https://schema.spaceapi.io/13.json", but they are not guaranteed to be network reachable.

In the case that it is not intended to deploy the noted uri over network, i personally would prefer an uri like urn:spaceapi:schema:root:0.13, not an actual url with https:// protocol an so on. just something to consider.

[dbrgn]

I think "pulling in other schemas" will never actually download the schema, it's only a reference. Or is there any OpenAPI client that actually does that?

In any case, I agree that an URN might be better! What do you think, @gidsi?

[miko007]

i am not aware of one, but i am just in the process of implementing validation for the SpaceAPI and stumbled over this scenario. i could imagine other people would, too.

probably this is due my lack of experience with json schema, i just assumed it would work like i know it from xml.

[gidsi]

It's definitely possible and i would like to make the schema available under the url (we've even talked about it, maybe there is even something in the protocols). Unfortunately we had a lot of other stuff on the agenda (if we start doing that we might also restructuring the schema files while we're on it).

Thats what the json-schema documentation says about using refs.

Even though the value of a $ref is a URI, it is not a network locator, only an identifier. This means that the schema doesn’t need to be accessible at that URI, but it may be. It is basically up to the validator implementation how external schema URIs will be handled, but one should not assume the validator will fetch network resources indicated in $ref values.

I would be against URN since nobody is using it out there and it might be confusing too.

[dbrgn]

I would be against URN since nobody is using it out there and it might be confusing too.

If it's just a unique identifier, then it's perfectly fine, right?

but one should not assume the validator will fetch network resources indicated in $ref values.

Also, that should usually not ever be done implicitly. In XML, external entities and external schemas have caused a whole load of security and information disclosure vulnerabilities: https://owasp.org/www-project-cheat-sheets/cheatsheets/XML_Security_Cheat_Sheet.html

I would not be against using URLs if the schema is actually served there. But I'm not sure if automatic fetching of referenced schemas should be encouraged.

[miko007]

In XML, external entities and external schemas have caused a whole load of security and information disclosure vulnerabilities

yes, i am aware of this. my specific usecase also was not to load the schemas in automatically, because i am not implementing a validator, just validation. i just wanted to tell the validator where to get his schemas from. i now include them in the project directly.

on the confusion part i stand by my opinion, that an uri would be much less confusing than an url that is not reachable.

[gidsi]

If it's just a unique identifier, then it's perfectly fine, right?

I'm not a 100% sure what you mean.

It's best practice to use your domain (json schema doc) and i would just do that instead of using an URN.

In my opinion we would just make the schemas reachable via https if it's confusing to not have it reachable there.

[gidsi]

Fixed by #73