URN wrongly reported as non-URI about ajv

[epoberezkin]

Thanks, I will have a look

[epoberezkin]

There are two issues here.

1. The string isn't a valid resource address (e.g. http://example.com) according to JSON-schema standard, that is a bit contradictory about what a valid URI is, but the test suite they supply mandates the presence of '//' (you can check formats file). For your kind of URN/URI you can either add a custom format or redefine URI format with ajv.addFormat('uri', /some_pattern/).
2. ajv.errorsText() without parameters will return errors as a string only if you used ajv.validate() rather than a compiled function (see examples in readme). Using compiled function is recommended as it is a bit faster. In this case you can access errors either via valid.errors (an array) or via ajv.errorsText(valid.errors) (a string).

[epoberezkin]

@nichtich with the latest change from @johanlelan URIs need to have at lease a single "/" character (was two slashes). Please feel free to reopen if my suggestions above are not working for you. Thanks

[nichtich]

Thanks for pointing to the sources and the second issue. My original bug report, however remains:

json-schema-validation spec. section 7.3.6. defines validation of the uri format as following:

A string instance is valid against this attribute if it is a valid URI, according to RFC3986

RFC 3986 lists some examples of URIs, several of them not containing a /. The specification contains a detailed grammar. Any regular expression for testing URI should allow at least this formal language. Sure ajv does not need to implemented all of its complexity but use a simplified regular expression.

[epoberezkin]

👍 It would be really great if you could suggest changes to the regular expressions ajv uses (in PR or just here).

[johanlelan]

I found this regular expression for generics URI on Regular Expression Cookbook (https://github.com/shihyu/Regular_Expressions/blob/master/O'Reilly-Regular%20Expressions%20Cookbook(2nd%20Edition).pdf)

^([a-z][a-z0-9+\-.]*:(\/\/([a-z0-9\-._~%!$&'()*+,;=]+@)?([a-z0-9\-._~%]+|\[[a-f0-9:.]+\]|\[v[a-f0-9][a-z0-9\-._~%!$&'()*+,;=:]+\])(:[0-9]+)?(\/[a-z0-9\-._~%!$&'()*+,;=:@]+)*\/?|(\/?[a-z0-9\-._~%!$&'()*+,;=:@]+(\/[a-z0-9\-._~%!$&'()*+,;=:@]+)*\/?)?)|([a-z0-9\-._~%!$&'()*+,;=@]+(\/[a-z0-9\-._~%!$&'()*+,;=:@]+)*\/?|(\/[a-z0-9\-._~%!$&'()*+,;=:@]+)+\/?))(\?[a-z0-9\-._~%!$&'()*+,;=:@\/?]*)?(#[a-zA-Z0-9\-._~%!$&'()*+,;=:@\/?]*)?$

It validates your urn @nichtich !
It validates the relatives URLs !
And of course, classics URLs :)

There is just one improvement to think about: case sensitive URIs.
For me URI are case insensitive but in real life, it depends on web server implementation.
So if you want to manage case sensitive URIs, juste replace a-z by a-zA-Z in all occurences.

Hope that helps!

[epoberezkin]

Cool, thanks!. Can be just /.../i

[epoberezkin]

The problem with that regex is that it also validates URI fragments (like 'abc'), and it shouldn't... It will fail the test. I'll see how it can be changed so URI fragments don't match.