JSON Pointer resolution requires a deterministic rule for duplicate object member names

Question

JSON Pointer reference token evaluation against an object with duplicate member names has no specified selection behavior. The JSON specification treats unique object names as a SHOULD rather than a MUST, so a conforming processor may accept documents where the same name appears multiple times. The JSON Pointer specification defines an error for a missing member but does not state whether evaluation must select the first match, the last match, or fail when several members share the token.

Because JSON Patch operations are defined in terms of JSON Pointer, the same ambiguity propagates into add, replace, remove, and test. The observable behavior can also depend on the host object model: dictionary-backed models may collapse duplicates to one value, while ordered pair-preserving models retain both entries. This creates a correctness risk where two processors accept the same bytes yet resolve a pointer to different values or produce different patch outcomes.

The missing constraint is whether a JSON Pointer implementation should require normalized documents with unique names, resolve to a deterministic member, or introduce a new error for ambiguous references. Should JSON Patch libraries reject or canonicalize duplicate names before applying operations? Which behavior should a configuration mandate for untrusted input?

Tasadduq Burney · Answer

Reject duplicate member names before pointer evaluation for untrusted input

For untrusted input, the configuration should mandate rejection of documents containing duplicate object member names before any JSON Pointer evaluation or JSON Patch operation. If rejection is not feasible, enforce a single canonicalization rule across all services, e.g., last-occurrence wins, and apply it before pointer resolution.

Confirmed facts

RFC 8259 states object member names SHOULD be unique, not MUST. RFC 6901 defines an error for a missing member but specifies no selection rule when multiple members share a token. RFC 6902 builds on JSON Pointer, so the ambiguity propagates to add, replace, remove, and test.

Likely explanation

Behavior depends on host object model. Map or dictionary-backed models collapse duplicates, often keeping the last value. Ordered pair-preserving models retain both entries, making pointer resolution implementation-defined. This yields divergent values and patch outcomes across processors.

Steps for this case

Validate input for duplicate keys and reject with 400 Bad Request if found.
If acceptance is required, canonicalize to a single value using a documented rule before pointer evaluation.
Verify library behavior with a test document containing duplicate keys and pointer /a.

To refine the recommendation, specify which JSON parser and JSON Pointer library version is in use, as default duplicate handling changes the risk profile.

JSON Pointer resolution requires a deterministic rule for duplicate object member names

1 answer

Reject duplicate member names before pointer evaluation for untrusted input

Confirmed facts

Likely explanation

Steps for this case

Your perspective belongs here.

0 question comments