Repository navigation
UriTemplate.match() does not percent-decode extracted values #2728
Description
Activity
I have reproduced this on current
mainand prepared a focused fix with regression coverage for percent-decoding values returned byUriTemplate.match(), including exploded lists and malformed encodings. I would like to take this issue and open a small PR.Thanks for taking a look. I offered to fix this when I filed it — I held off writing the PR because
AGENTS.mdsays a PR needs an issue assigned to its author, so I have the differential harness that surfaced it but nothing pushed.Happy for a maintainer to assign whichever of us they'd rather have on it.
I prepared a ready-to-review fix on
edenbuilds:codex/hunt-mcp-2728(compare: main...edenbuilds:codex/hunt-mcp-2728).It decodes scalar and exploded-array captures in
UriTemplate.match()withdecodeURIComponent, while retaining malformed components as-is so matching stays non-throwing. The two regression tests were verified red with the source fix stashed, then green after the fix. Focused result: 2 passed, 38 skipped; core-internal typecheck passed; the repository pre-push hook passed Build (46s), Typecheck (52s), and Lint (137s).Commits
e6bf4565andb2ddf4fdare both attributed toedenbuilds. My account cannot create PRs in this repository (CreatePullRequestpermission denied), so please open the PR from the branch or let me know if you prefer a maintainer cherry-pick.I reproduced this on current
mainand confirmed thatexpand()percent-encodes variable values whilematch()returns the encoded capture. I plan to decode matched variable values withdecodeURIComponent, add focused round-trip coverage for spaces, reserved characters, and non-ASCII input, and preserve malformed-escape handling without changing template matching semantics.
Describe the bug
expand()percent-encodes variable values, butmatch()returns them still encoded, so the two are not inverses:Round-tripping 10 templates against 20 values, 147 of 200 fail — every value containing a space,
/,?,#,&,=,%, or a non-ASCII character. A few from that sweep:expandmatchreturnsfile:///{path}a bfile:///a%20ba%20bfile:///{path}a/bfile:///a%2Fba%2Fbfile:///{path}üfile:///%C3%BC%C3%BCx://h/{a}/{b}a#bx://h/a%23b/a%23ba%23bThere is no
decodeURIComponentcall anywhere inpackages/core-internal/src/shared/uriTemplate.ts.Impact
ResourceTemplateroutes resource URIs throughmatch(), so a handler receives the encoded string rather than the value the client asked for. Any resource whose template variable contains a space or a non-ASCII character is handed the wrong value, silently.Prior art I checked
The open
uriTemplatePRs — #2633, #2170, #2429, #2216, #2218 — all cover multi-variable or optional matching, and none of them adds a decode call. #1785's title mentioned encoded query parameters, but it closed unmerged and the decoding does not appear in its successors, so this axis looks genuinely open.Environment
Reproduced on
@modelcontextprotocol/sdk1.30.0 and confirmed present onmain.Happy to open a PR if you assign this to me.
Disclosure, per the org AI policy: I used AI assistance for this investigation and write-up — the differential harness that surfaced it and the drafting of this issue. The finding is reproduced and verified, and I can discuss any part of it.