Resolution scope doesn't use the entire URL

[vjrasane]

Hello,

I'm using json-schema to validate incoming JSON data to a Spring application. Some of the schemas have relative references to other schemas served by the same Spring application. So for example the schema:

{
    "$schema": "http://json-schema.org/draft-04/schema#",
    "properties": {
        "url": {
            "$ref": "/interface#/definitions/Operation"
        }
    }
}

References another schema called "interface". I've used the following code to set the resolution scope:

String schemaUrl = "http://localhost:8091/ServiceDesign/api/v1/validation/";
SchemaLoader loader = SchemaLoader.builder().schemaJson(schemaJson).resolutionScope(schemaUrl).build();
            return loader.load().build();

Unfortunately, it looks like only the host name and port are used in the query, as I get the following stacktrace:

java.io.UncheckedIOException: java.io.FileNotFoundException: http://localhost:8091/interface
	at org.everit.json.schema.loader.internal.DefaultSchemaClient.get(DefaultSchemaClient.java:35)
	at org.everit.json.schema.loader.internal.JSONPointer.executeWith(JSONPointer.java:81)
	at org.everit.json.schema.loader.internal.JSONPointer.lambda$forURL$1(JSONPointer.java:133)
	at org.everit.json.schema.loader.internal.JSONPointer.query(JSONPointer.java:152)
	at org.everit.json.schema.loader.ReferenceLookup.lookup(ReferenceLookup.java:99)
	at org.everit.json.schema.loader.SchemaLoader.buildSchemaWithoutExplicitType(SchemaLoader.java:253)
	at org.everit.json.schema.loader.SchemaLoader.lambda$load$0(SchemaLoader.java:290)
	at java.util.Optional.orElseGet(Optional.java:267)
	at org.everit.json.schema.loader.SchemaLoader.load(SchemaLoader.java:288)
	at org.everit.json.schema.loader.SchemaLoader.loadChild(SchemaLoader.java:346)
	at org.everit.json.schema.loader.ObjectSchemaLoader.lambda$addPropertySchemaDefinition$4(ObjectSchemaLoader.java:79)
	at org.everit.json.schema.loader.internal.TypeBasedMultiplexer$IdModifyingTypeConsumerImpl.lambda$then$0(TypeBasedMultiplexer.java:78)
	at org.everit.json.schema.loader.internal.TypeBasedMultiplexer.orElse(TypeBasedMultiplexer.java:233)
	at org.everit.json.schema.loader.internal.TypeBasedMultiplexer.requireAny(TypeBasedMultiplexer.java:243)
	at org.everit.json.schema.loader.ObjectSchemaLoader.addPropertySchemaDefinition(ObjectSchemaLoader.java:81)
	at org.everit.json.schema.loader.ObjectSchemaLoader.lambda$populatePropertySchemas$3(ObjectSchemaLoader.java:70)
	at java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
	at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)
	at org.everit.json.schema.loader.ObjectSchemaLoader.populatePropertySchemas(ObjectSchemaLoader.java:69)
	at org.everit.json.schema.loader.ObjectSchemaLoader.lambda$load$0(ObjectSchemaLoader.java:34)
	at org.everit.json.schema.loader.internal.TypeBasedMultiplexer$IdModifyingTypeConsumerImpl.lambda$then$0(TypeBasedMultiplexer.java:78)
	at org.everit.json.schema.loader.internal.TypeBasedMultiplexer.orElse(TypeBasedMultiplexer.java:233)
	at org.everit.json.schema.loader.internal.TypeBasedMultiplexer.requireAny(TypeBasedMultiplexer.java:243)
...

Is this by design? I tried to follow the instructions on the GitHub page, but perhaps I'm using the library wrong?

[erosb]

Hello, can you reproduce it with version 1.9.1 ?
The $ref handling was rewritten (mostly) since 1.5.1 , I'm not sure if upgrading solves your problem.

[vjrasane]

Hey,
Reproduced the same issue with 1.9.1, i.e. got the same error:
java.io.FileNotFoundException: http://localhost:8091/interface

The second issue that I mentioned about the refs had been fixed though, I'll edit the post.

[erosb]

Ok, I will try to find some time to look into this. In the meanwhile it would be useful if you could submit a PR with a reproduction test. Thanks!

[vjrasane]

I created a pull request with a crude test case, but the problem is that there doesn't seem to be a way to set the reference path for the test. Correct me if I'm wrong or if there's another way to create the test.

[erosb]

What would be the reference path in this testcase?

[vjrasane]

Hmm, now that I look at it I think the reference path in that test would be simply "http://localhost:1234", since "references" is explicitly stated in the $ref. It should actually be just "/example.json#/definitions/Example" and then the reference path would be "http://localhost:1234/references". I'll update the test.

[erosb]

Hello @vjrasane ,

I added support in integration tests to specify the base URL / reference path (well it is actually called "resolution scope" by the library).

After investigating your testcase in more detail I found that the current behavior is correct. The JSON Schema specification says the following: "The value of the "$ref" property MUST be a URI Reference. Resolved against the current URI base"

I looked up the RFC specifying URIs , it includes pseudo-code for URI reference resolutions. According to this, your schema had 2 problems:

• the URI reference started with a slash (/example.json#/definitions/Example). This means that the path component of the base URI is not included in the result (you can figure it out from their pseudo-code)
• the base URL was http://localhost:1234/references , without a trailing slash. According to section 5.2.3 in the same RFC, in this case the references path segment is excluded from the resolved URI.

(sidenote: the relative URL spec defines the very similar - if not the same - resolution algorithm for URLs too, just with different wording).

I pushed in a separate commit a fix to your testcase, you can take a look.