samples/restApi: buffer template render before flushing to response

[randomizedcoder]

⚠️ Depends on #124

This branch is based on the head of fix/g708-template-injection (PR #124), not on main directly. The diff against main includes #124's commit too. Please review #124 first; once it lands, this rebases onto main trivially. If you'd rather see them combined into one PR, happy to do that — say the word.

Hi 👋

While writing tests for #124 I noticed an existing wart in printer() and documented it in the test file with a comment calling it "out of scope for the G708 hardening." This PR is that follow-up.

The bug

printer() and processPrint() call Execute(resp, ...) directly:

if err := tmpl.Execute(resp, stats); err != nil {
    http.Error(resp, err.Error(), http.StatusInternalServerError)  // can't actually set 500
    log.Printf(...)
}

text/template writes the static template prefix to the output before evaluating the first {{action}}. On a ResponseWriter that prefix flush implicitly commits HTTP 200. If a later action then fails (stats missing a field, etc.), the http.Error() call cannot actually set status 500 — the headers are already on the wire — so the client silently gets 200 OK with a body containing both the partial template prefix and the error message.

You can see this happen in #124's existing test:

// out of scope for the G708 hardening:
"negative_unknown_field_appends_error_in_body", ...
http.StatusOK, "can't evaluate field Memory", "",

The StatusOK is the wart.

The fix

Execute into a bytes.Buffer; copy to resp only on success. On render failure the buffer is discarded and http.Error() writes a clean 500 with the template error message. No partial template output leaks to the client.

TDD

Drove the existing negative case to red by flipping its assertions:

-"negative_unknown_field_appends_error_in_body", ...
-http.StatusOK, "can't evaluate field Memory", "",
+"negative_unknown_field_returns_500_with_clean_body", ...
+http.StatusInternalServerError, "can't evaluate field Memory", "Memory(KB)",

The new notSubstr="Memory(KB)" is the strong assertion — it proves the partial template prefix never escapes the buffer.

Then implemented printer() and watched the case go green. All 18 cases pass.

Why this is low risk

• Same public surface (printer/processPrint signatures unchanged from samples/restApi: pre-parse templates (gosec G708 hardening) #124).
• Behavior change limited to the failure path — the success path is byte-for-byte identical (still copies the template output to the response).
• All 9 sample binaries build cleanly.
• processPrint() gets the same structural treatment for symmetry; the test suite can't trigger a processInfo render failure today, so the fix there is defensive (visible in the diff).

Test plan

• go build ./samples/restApi/...
• go test -v -count=1 ./samples/restApi/handlers/... — 18/18 pass
• go vet ./samples/restApi/...
• gofmt -l samples/restApi/handlers/ — empty
• CI green

🤖 Generated with Claude Code