You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and pull requests for this behavior.
Description
resource_url_from_server_url() lowercases the scheme/authority and removes the fragment, but it preserves an explicitly specified default port. This makes an RFC 8707 resource URL such as https://example.com:443/mcp compare unequal to the equivalent https://example.com/mcp value used by Protected Resource Metadata.
RFC 3986 section 6.2.3 treats an explicit default port as equivalent to an omitted port. Pydantic also normalizes the metadata URL by dropping the default port. The SDK currently canonicalizes only one side, so check_resource_allowed() can reject an otherwise equivalent resource and abort OAuth resource validation.
Expected: HTTP port 80 and HTTPS port 443 are removed during canonicalization; non-default ports remain unchanged.
I reproduced the behavior and reviewed the two existing implementations in #3299 and #3310, so I will not open a third duplicate PR.
One scope question remains before any additional work: this issue is labeled v1 and v2, but the contribution guide limits v1.x to security and critical bug fixes while this issue is P3. Should the intended fix target main only?
Whichever existing implementation is selected, I suggest keeping the regression matrix focused on:
stripping only HTTP :80 and HTTPS :443;
preserving non-default and malformed ports;
preserving userinfo, bracketed IPv6, path, and query components;
retaining the existing fragment-removal behavior.
#3299 is narrower and already covers IPv6 and malformed authorities; #3310 additionally canonicalizes both inputs in check_resource_allowed(), which may be useful but is a broader semantic change than the reported helper bug.
AI-assisted investigation disclosed; I reviewed the issue, contribution policy, both diffs, and their CI results and remain accountable for this analysis.
Activity
Ben-Home commentedon Aug 14, 2026
tao943 commentedon Aug 20, 2026
I reproduced the behavior and reviewed the two existing implementations in #3299 and #3310, so I will not open a third duplicate PR.
One scope question remains before any additional work: this issue is labeled
v1andv2, but the contribution guide limitsv1.xto security and critical bug fixes while this issue isP3. Should the intended fix targetmainonly?Whichever existing implementation is selected, I suggest keeping the regression matrix focused on:
:80and HTTPS:443;#3299 is narrower and already covers IPv6 and malformed authorities; #3310 additionally canonicalizes both inputs in
check_resource_allowed(), which may be useful but is a broader semantic change than the reported helper bug.AI-assisted investigation disclosed; I reviewed the issue, contribution policy, both diffs, and their CI results and remain accountable for this analysis.