RefValidator on non-http (classpath & other custom protocol) URL breaks schema loading

[gotchazipc]

Hi. I found RefValidator resolves a bad URL when a $ref value points non-http URL.

For classpath:/ URL,
When schema a having id classpath:/some_path/a.json has a $ref value to classpath:/some_path/b.json, URLFetcher tries to load classpath:/some_path/classpath:/some_path/b.json
it seems to be a bug of RefValidator#obtainAbsolutePath()

Changing $ref value to '/some_path/b.json' was looked promising but didn't help. RefValidator#obtainAbsolutePath() returned classpath//some_path/b.json, lacking colon. After changing $ref value to './b.json', it worked as expected.

For some custom URL, like some_protocol:/some_path/some_file_name.json, I met similar but more complex problems. After digging into code, I found

1. As classpath:/... URLs, absolute URL is treated as relative. RefValidator regards any URL string which does not start 'http' as an relative URL.

2. URLFactory.toURL() always refers ClasspathURLStreamHandler and there's no way to override the factory. That means, the custom protocol URL string cannot be changed into URL object but throws MalformedURLException. Then, RefValidator catches the exception and it tries to interpret whole URL string as some resource path. Finally some unexpected NPE is thrown in somewhere else.

First one could be solved easily but second problem looks a little bit serious. Relying on URL & URLConnection to load sub-schema doesn't look so good, for managing stream handler factory and many properties on making/managing connections using URL is static or VM-wide, using system properties. Even though URLFetcher can be customized using interface & JsonSchemaFactory.builder(), it's not possible to load URL with custom scheme.

To provide more flexible customization on loading schema, I hope we could have better design. URLFetcher need to accept string instead of URL, and internal code may need to be changed using URI instead of URL.

[stevehu]

@gotchazipc I agree with you that reference URL needs to be handled correctly. I have done a lot of work in the openapi-parser for parsing and validation. Here is a utility module that I think would help to extend the functionality. Need to find time to enhance this library.

https://github.com/networknt/light-4j/tree/develop/http-url

[stevehu]

This issue should be resolved by PR #141