Update ExternalRefProcessor.java

[Emad89]

Objects are duplicated in the following situation:

If object A is referenced as a response in API_endpoint1, And object B is a response for API_endpoint2, where B has a property that references A.
When resolving paths:

• A path resolved from API_endpoint1 looks like this: ./../A.

• A path resolved from B looks like this: ../A.

In this scenario, the presence of both ./ and ../ can lead to the creation of duplicated objects.

[ewaostrowska]

Thanks for the PR @Emad89! The duplicate-schema problem is real, but I don’t think this implementation is safe to merge.

The patch fixes only one case: ../A and ./../A become the same string. But proper URI normalization is more than adding ./. OpenAPI says relative $refs are resolved against the current document, and RFC 3986 says . and .. segments should be removed during reference resolution.

For example, dir/../A and A can point to the same resource, but this patch still treats them differently. More importantly, swagger-parser also classifies paths starting with / as RELATIVE, so /tmp/A.yaml would become .//tmp/A.yaml, changing an absolute-path reference into a relative path. RFC 3986 explicitly distinguishes these forms.

There is also a real regression: the existing testRelativeRefIncludingUrlRef uses an HTTPS reference while processing a relative ref. With this patch, that URL can become ./https://....

I am closing this PR as the #2105, addresses the same problem by resolving equivalent paths rather than only adding a prefix, and includes a targeted reproduction fixture.