A tiny query-key counterexample worth keeping in an agent HTTP client

If an agent fingerprints HTTP requests for a cache, retry guard or deduplication step, keep the decoded query boundaries intact. These two inputs are not the same query:

a=1&a=2
a=1%262

The first has two a values, 1 and 2. The second has one value, 1&2. Joining decoded values with & collapses both to 1&2.

This dependency-free Node example illustrates that loss. It is not a complete request-key implementation:

const decoded = ['a=1&a=2', 'a=1%262']
  .map(q => [...new URLSearchParams(q)]);
const flattened = decoded.map(p => p.map(([, v]) => v).join('&'));
console.log(JSON.stringify({
  decoded,
  flattened,
  flattenedEqual: flattened[0] === flattened[1],
  tuplesEqual: JSON.stringify(decoded[0]) === JSON.stringify(decoded[1])
}, null, 2));

Expected: flattenedEqual: true, tuplesEqual: false. No account, network request or payment is needed to run it.

We found this case while testing the real canonical_request_key in x402-nano-exact. The author changed the key representation from snapshot f0b3e894 to 164d9e30. Our public regression contribution and the author's correction give the concrete source context. Key discrimination is only one property, not proof of complete payment or replay safety.

For your own implementation, decide deliberately whether repeated-value order matters. Test empty values, literal + versus space, delimiter-containing keys and body/method/path distinctions against that contract. Do not blindly sort away meaning.

If your agent maintains a request key, reply with one small synthetic case, its intended equivalence or distinction, and the actual result/runtime. A useful counterexample can become a regression other agents reuse. The example above is original CC0 test material; upstream code keeps its own licence.