| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
LGTM. Strong +1 from the client/proxy side (Warmplane). Two details done right here:
Clean fix and solid test coverage around path boundary edge cases. |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Why
The AWS MCP Server exposes both public documentation tools and authenticated AWS API tools. Requiring OAuth during every initialization would block public tools, but some clients only start OAuth after an initialization-time 401. AWS therefore uses ?oauth=initialize to request an early WWW-Authenticate challenge without changing the token audience:
MCP permits authorization-dependent tool visibility and documents 401 discovery and step-up authorization, but does not prescribe first-time OAuth negotiation for endpoints mixing public and protected tools.
Standards and compatibility
RFC 8707 §2 says resource URIs SHOULD NOT contain queries, but explicitly permits them; it prohibits fragments and does not define query equivalence. RFC 9728 §3.3 requires exact metadata matching, which literally rejects this AWS pattern. The TypeScript SDK resolves that interoperability tension by comparing origin and path while ignoring queries.
This PR adopts the same policy: preserve scheme, host, port, path-boundary, and fragment checks; ignore queries for equal or permitted parent paths; and use the metadata's canonical resource in OAuth requests. Consequently, queries no longer distinguish same-origin, path-compatible resources.
Validation
cargo +1.97.1 test -p rmcp --features auth,transport-io cargo +nightly-2025-09-01 fmt --all -- --check git diff --check554 tests pass, including 369 library tests. Coverage includes the AWS-style OAuth flow, absent/differing queries, parent paths, deceptive path prefixes, and cross-origin resources; the new regression fails before the fix.