Schema id does not declare a base URL for relative $ref URLs

[xaviarias]

When resolving relative $references, URLs are constructed using the reference value directly without using the base URL of the referencing schema.

https://spacetelescope.github.io/understanding-json-schema/structuring.html?highlight=dependencies#the-id-property

For example, if you own the foo.bar domain, and you had a schema for addresses, you may set its id as follows:

"id": "http://foo.bar/schemas/address.json"

This provides a unique identifier for the schema, as well as, in most cases, indicating where it may be downloaded. For example: { "$ref": "person.json" }

A JSON schema validation library would fetch person.json from http://foo.bar/schemas/person.json, even if address.json was loaded from the local filesystem.

[eskabetxe]

i was this issue too..
@stevehu i will check this..

[eskabetxe]

created PR
#37

it could be better, if we can had some level of cache for the url/content, it would not be necessary to be downloading the content to each $ref as it always made "new RefValidator"

[stevehu]

@eskabetxe I think it is cached as we only parse schema in the factory once. And all the validators are created during parsing and cached in a map. I didn't look at the code but make the comment based on the way it was implemented. If you could confirm that we parse the ref on a per request basis, then we definitely need to get it fixed. Could you please confirm? Thanks.

[eskabetxe]

for this example
{ "$schema": "http://json-schema.org/draft-04/schema#", "id": "http://localhost:8080/testing.json", "properties": { "prop1": { "$ref": "rules.json#/prop1" }, "prop2": { "$ref": "rules.json#/prop2" }, "prop3": { "$ref": "rules.json#/prop3" } } }

the $ref file (rules.json) will be charge 3 times..
because for each prop we create a new RefValidator that will download rules.json and check the proper rule

i think that prop1, prop2, etc are cached, but the file rules.json is download 3 times and this could be improved

[stevehu]

This issue should be resolved by #141