Reference resolution issue

[bolshakov]

We use json-schema in a multi-threaded environment, and as outlined in issues #310 and #242, the heavy use of caching at the class level could potentially lead to race conditions.

We encounter this problem intermittently. In trying to reproduce the issue, I discovered a problem with the JSON::Util::URI.normalize_ref method, which can be reproduced even without using multiple threads:

assert_equal Addressable::URI.parse('http://www.example.com/#foo'), JSON::Util::URI.normalize_ref("#foo", 'http://www.example.com')
assert_equal Addressable::URI.parse('http://www.example.net/#foo'), JSON::Util::URI.normalize_ref("#foo", 'http://www.example.net')

The test above fails with the following output:

Minitest::Assertion: --- expected
+++ actual
@@ -1 +1 @@
-#<Addressable::URI:0xb54 URI:http://www.example.net/#foo>
+#<Addressable::URI:0xb68 URI:http://www.example.com#foo>

The errors disappear if the cache is cleared between assertions. Apparently, the implementation of the .normalize_ref method stores parsed #foo in the cache and subsequently modifies it by extending it with the base URL. Therefore, the same ref could be resolved differently, ignoring the base argument entirely.

Steps to Reproduce

1. Run the following test:

   assert_equal Addressable::URI.parse('http://www.example.com/#foo'), JSON::Util::URI.normalize_ref("#foo", 'http://www.example.com')
   assert_equal Addressable::URI.parse('http://www.example.net/#foo'), JSON::Util::URI.normalize_ref("#foo", 'http://www.example.net')

2. Observe the failure and the incorrect URI being returned due to cache usage.

3. Clear the cache (JSON::Util::URI.clear_cache) between assertions to see the errors go away.

You can find the problem reproduced in this PR #515

Expected Behavior

The JSON::Util::URI.normalize_ref method should respect the base argument and resolve the reference correctly for each call.

Actual Behavior

The method caches the parsed ref argument and incorrectly resolves it by ignoring the base argument on subsequent calls.

[macfanatic]

Did #515 actually resolve this issue? I ask because the issue is still open, and that's unclear.

Came here from v5.0.0 release notes.

[bolshakov]

yes, it did