Fix : MCP resource validation by normalizing trailing slashes in URLs

[hihry]

fix : #259495

This PR fixes an issue where MCP resource URL validation could fail due to differences in trailing slashes (e.g., https://example.com/ vs https://example.com).
The comparison now normalizes URLs before checking equality, preventing false mismatches.

[TylerLeonhardt]

From https://datatracker.ietf.org/doc/html/rfc9728#section-3.3

If the protected resource metadata was retrieved from a URL returned by the protected resource via the WWW-Authenticate resource_metadata parameter, then the resource value returned MUST be identical to the URL that the client used to make the request to the resource server. If these values are not identical, the data contained in the response MUST NOT be used.

Actually your example works. http://example.com/ is the same as http://example.com... However, http://example.com/foo is not the same as http://example.com/foo/ and should be rejected based on the spec.

So unfortunately, this is not the right approach

[hihry]

Thanks for the clarification, @TylerLeonhardt . I understand now that the OAuth spec requires an exact match for the resource URL and that normalizing (removing trailing slashes) would violate this requirement.

My intention was to avoid false mismatches, but I see that’s not spec-compliant. I’ll update this PR to:

-Keep strict URL comparison as per the spec.

-Improve the error message so that users understand when a mismatch is due to trailing slash differences.

-Investigate handling the picker closing issue separately in the UI so it doesn’t get blocked by this mismatch.
I’ll make the changes accordingly.