fix: encode literals per RFC 6570 3.1, and label the varname tolerance
Addresses Copilot's round-10 review on #2035. One inline comment, one
suppressed; both real.
1. Literals were copied through verbatim, but RFC 6570 3.1 requires them
pct-encoded on expansion -- the conformance case `café/{var}` expands to
`caf%C3%A9/value`. Measured on ef3f5e74 it produced `café/value`, raw
UTF-8 in the path; since this module replaced the SDK's expander for both
clients, nothing else was going to encode it. (The pinned SDK does not
either -- it returns `café/value` too -- so this is a gap we inherited
rather than introduced.)
`encodeLiteral` keeps reserved delimiters (a literal's `/`, `?` and `#`
are structure) and existing pct-triplets, and encodes the rest. A BRACE
passes through: it can only reach a literal from a malformed template,
where an unclosed `{` becomes trailing text, and `%7B` would leave a
string resembling neither the template nor anything the server can match.
This is also what removed the preview's placeholder machinery. No token
can survive a round trip now that literals are encoded, so the preview
assembles part by part instead -- `encodeLiteral` for literal runs,
`expandTemplateExpression` for filled expressions, `part.source` for the
rest. Both halves still come from the shared expander, so the preview
cannot promise a URI that submitting would not send, and the question of
what token could never collide with a server-supplied template is gone.
2. On the varname set I took the structural point rather than the
conclusion. `VARCHAR` is RFC-exact again; `-` and `~` moved into a
separately named `TOLERATED_VARCHAR` tier, and a name needing it parses
with `conforming: false`, surfaced on `TemplateVariable`.
So the grammar in the code says what the RFC says and the tolerance is
explicit and separately tested -- but the Inspector still expands
`{default-graph-uri}`, because real servers publish hyphenated names and
the SDK's matcher round-trips them. Refusing to read a resource that
demonstrably works is a worse failure for a debugging tool than expanding
a name the conformance suite would reject. A caller wanting RFC-exact
behavior refuses on the flag rather than re-deriving the grammar.
npm run ci passes.
Signed-off-by: cliffhall <cliff@futurescale.com>
This commit is contained in:
parent
ef3f5e74d8
commit
2e06b369f4
1 changed files with 225 additions and 98 deletions
|
|
@ -79,3 +79,23 @@ describe("preview with Object.prototype-colliding names", () => {
|
|||
);
|
||||
});
|
||||
});
|
||||
|
||||
describe("previewUriTemplate - literals", () => {
|
||||
// The preview promises the URI that submitting would send, so it applies the
|
||||
// same RFC 6570 3.1 literal encoding the wire does.
|
||||
it("percent-encodes a non-ASCII literal", () => {
|
||||
expect(previewUriTemplate("café/{var}", { var: "value" })).toBe(
|
||||
"caf%C3%A9/value",
|
||||
);
|
||||
});
|
||||
|
||||
it("encodes the literal even while an expression is still unfilled", () => {
|
||||
expect(previewUriTemplate("café/{var}", {})).toBe("caf%C3%A9/{var}");
|
||||
});
|
||||
|
||||
it("keeps a malformed template legible rather than encoding its brace", () => {
|
||||
expect(previewUriTemplate("x://café/{oops", {})).toBe(
|
||||
"x://caf%C3%A9/{oops",
|
||||
);
|
||||
});
|
||||
});
|
||||
|
|
|
|||
Loading…
Reference in a new issue