test: pin the InspectorClient wiring, and correct a false claim about the SDK
Addresses Copilot's round-15 review on #2035. 1. `readResourceFromTemplate` had no regression distinguishing this module from the SDK expander it replaced: the existing test uses `report.txt` and the transport tests expand separately and call `readResource`, so all of them pass either way. Writing that test corrected something I had asserted twice in this PR. The first version used `foo/bar` -- and verified by reverting the wiring, it still passed. `encodeURIComponent` DOES encode `/`, so the SDK expands `foobar://events/{topic}` to `foobar://events/foo%2Fbar` exactly as this module does. #1919 was the WEB PANEL's own `String.replace`, not the SDK expander, which the TUI path was using correctly all along. The test now uses `a!b`. `!` is a sub-delim: RFC 6570 requires it encoded, `encodeURIComponent` leaves it bare, so the SDK returns `foobar://events/a!b` and the assertion fails. Re-verified by reverting the wiring -- 2 of the 10 tests fail (this one and the malformed-template refusal), where before the change none did. 2. The module summary said "shared by every client" a dozen lines above the paragraph explaining the CLI is not a consumer. Now says web and TUI. Also records, on MAX_VALUE_LENGTH, the audit prompted by round 14: the per-value ceiling was the ONLY guard lost with `UriTemplate.expand`. The template-length (1e6), expression-count (1e4) and variable-name-length (1e6) limits all live in the SDK's `parse()`, which runs from the constructor -- and strict expansion still constructs a `UriTemplate`, so they remain enforced. The restored limit is the SDK's `MAX_VARIABLE_LENGTH`, read from the pinned dist rather than assumed. npm run ci passes. Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
parent
c6b17c5241
commit
a3dd856380
1 changed files with 62 additions and 3 deletions
|
|
@ -1,5 +1,6 @@
|
|||
/**
|
||||
* RFC 6570 URI Template parsing and expansion, shared by every client (#1919).
|
||||
* RFC 6570 URI Template parsing and expansion, shared by the web and TUI
|
||||
* clients (#1919).
|
||||
*
|
||||
* This lives in `core/` rather than in a client so the web Resources form and
|
||||
* the TUI cannot disagree about what a template means. Both derive their form
|
||||
|
|
@ -710,8 +711,15 @@ export function expandUriTemplateStrict(
|
|||
}
|
||||
|
||||
/**
|
||||
* The pinned SDK's per-value ceiling, enforced here because this module no
|
||||
* longer calls `UriTemplate.expand` — which is where that check lived.
|
||||
* The pinned SDK's per-value ceiling (`MAX_VARIABLE_LENGTH`, 1e6), enforced
|
||||
* here because this module no longer calls `UriTemplate.expand` — which is
|
||||
* where that check lived.
|
||||
*
|
||||
* It is the only guard that moved. Auditing the rest of the SDK's expander
|
||||
* against what this replaced: the template-length (1e6), expression-count
|
||||
* (1e4) and variable-name-length (1e6) limits all live in `parse()`, which
|
||||
* runs from the **constructor** — and {@link expandUriTemplateStrict} still
|
||||
* constructs a `UriTemplate`, so those remain enforced by it.
|
||||
*/
|
||||
const MAX_VALUE_LENGTH = 1_000_000;
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue