Recent implementation work resolving #209 has resulted in a significant weakening of URL validations. The reasons are:
The OAS specification (v3.0.2 draft) states:
Unless specified otherwise, all properties that are URLs MAY be relative references as defined by RFC3986. Relative references are resolved using the URLs defined in the Server Object as a Base URI.
In this context "relative reference" is used as in the referenced RFC, in the context of paths in hierarchical URLS. This has nothing to do with JSON references, except that reference strings in the latter may themselves include relative references, which are in that case resolved relative to the URL of the containing document.
As far as I can say, "specified otherwise" does not hold anywhere in the specification, so at this point I conclude that all URL fields should permit relative URLs, despite the fact that some explicitly say so and others do not.
This is probably not correct, but following a practice of preferring false negatives to false positives, KZOP currently permits relative URLs for all URL properties.
So that's one problem with URL validation - it's probably allowing relative URLs where they're not intended.
The second problem is that the current validation implementation is very weak, especially in the case of relative URLs.
The problems are that:
The URL(string) constructor allows lots of clearly bogus URL strings to succeed without throwing an exception. Apparently, many scheme-specific checks don't happen until the URL is opened.
The URL(URL, string) constructor, which is currently used to validate relative URLs, appears to let nearly anything through! E.g. http/:/ds, which is clearly not "relative" at all, but when used with a context URL, is accepted just fine.
What I propose for this is to not rely at all on URL constructors. Instead, use two steps:
Use regex or other means to verify that the string conforms to the general syntactic requirements of the applicable RFC. This should handle both absolute and relative URLs, and the check should also permit us to distinguish the two.
If step 1 passes and the URL is absolute, use Apache commons-validation to perform further validation. This will include scheme-specific checks for several common schemes.
If step 1 succeeds and step 2 fails due to unrecognized scheme, validation passes.
If step 1 succeeds and the URL is relative validation passes or fails depending on whether relative URLs are permitted.
Recent implementation work resolving #209 has resulted in a significant weakening of URL validations. The reasons are:
So that's one problem with URL validation - it's probably allowing relative URLs where they're not intended.
The second problem is that the current validation implementation is very weak, especially in the case of relative URLs.
The problems are that:
URL(string)constructor allows lots of clearly bogus URL strings to succeed without throwing an exception. Apparently, many scheme-specific checks don't happen until the URL is opened.URL(URL, string)constructor, which is currently used to validate relative URLs, appears to let nearly anything through! E.g.http/:/ds, which is clearly not "relative" at all, but when used with a context URL, is accepted just fine.What I propose for this is to not rely at all on URL constructors. Instead, use two steps: