In WireMock, why does a templated body render " where a quote should be?

## Why a quote turns into an entity WireMock's response templating is Handlebars, and Handlebars has one behaviour that surprises everybody who meets it outside a web page: a `{{ expression }}` is **HTML-escaped** on the way out. Five characters are rewritten — `"` to `&quot;`, `'` to `&#x27;`, `&` to `&amp;`, `<` to `&lt;` and `>` to `&gt;`. In a template that produces HTML this is a safety feature and the reason the default exists. In a WireMock stub answering a snowplough dispatch API with JSON, it is a corruption. The symptom is unmistakable once you have seen it. The stub answers `201` as designed, the body has the right fields in the right order, and every embedded quote is an entity: - Expected: `{"manifest": {"laneKm": 14, "saltTonnes": 3}}` - Rendered: `{&quot;manifest&quot;: {&quot;laneKm&quot;: 14 ...` No client will parse that, and no WireMock log will complain about it, because from the server's point of view nothing went wrong. ## Double brace versus triple brace | Form | What WireMock emits | Use it for | |---|---|---| | `{{jsonPath request.body '$.notes'}}` | the helper's output, HTML-escaped | text destined for an HTML body, where escaping is protection | | `{{{jsonPath request.body '$.notes'}}}` | the helper's output exactly as produced | JSON, XML, and any document you are assembling character by character | The triple brace is not a WireMock invention; it is the Handlebars escape hatch, and WireMock inherits it along with the escaping default. Nothing else about the expression changes — same helper, same arguments, same source — only whether the result is rewritten before it lands in the reply. ## What the triple brace hands back to you Switching a WireMock template to `{{{ }}}` does not remove the escaping problem, it transfers ownership of it: - A value that contains a `"` will now terminate the JSON string you placed it in, producing a body that is malformed in a new way. - A value that contains a newline will do the same, because a raw newline is not legal inside a JSON string. - A value taken straight from the request is attacker-controlled in exactly the sense a real service would care about, and the stub is now concatenating it into a document. The practical division that follows: 1. **Whole sub-documents** — a manifest, a nested object, an array pulled out of the request — belong in a triple brace, unquoted, because the helper's output is already valid JSON and quoting it would be wrong twice over. 2. **Scalars you control** — a route id, a depot code, an enum value — are safe in a triple brace inside quotes, because you know their shape. 3. **Free text of unknown shape** — an operator's note, a caller-supplied description — is the case with no clean answer. Either keep it out of the templated reply, or accept that a stub is not the place to do robust escaping and pin the fixture to a value you chose. ## Where this bites on a dispatch API The classic version is a confirmation reply that echoes the submitted manifest back. The WireMock stub author writes `"manifest": "{{jsonPath request.body '$.manifest'}}"` — quoted, double brace — and gets two defects at once: the sub-document has been flattened into a string, and every quote inside it has become an entity. In WireMock the correct shape is `"manifest": {{{jsonPath request.body '$.manifest'}}}` with no surrounding quotes at all, because the helper already yields a JSON object. The second version is subtler. A field renders fine in every test until a caller submits a route note containing an apostrophe, and one test in a nightly run starts failing on a body it cannot parse. The template did nothing different; the data did. ## Deciding which form to write 1. Ask what the rendered value is going into. HTML wants the double brace; JSON and XML almost always want the triple. 2. Ask whether the value is a document or a scalar. A document goes in unquoted with a triple brace; a scalar goes inside quotes. 3. Ask who controls the value's characters. If the answer is "the caller", either narrow the stub's matcher so only known-shaped payloads reach it, or stop echoing that field. 4. Read the rendered reply once against a realistic request, not a minimal one. A body of clean identifiers hides this defect completely. The reason this belongs to production judgment rather than to trivia is that every failure mode here is silent. WireMock's escaping default is applied without comment, the triple brace's hazards are applied without comment, and the only signal in either direction is a client that could not read a reply the stub server considered a success.