GeezerVison

What this is

A small change to the echo and echo-v5 server templates so that the error responses generated servers send back to clients don't include the underlying Go error text.

What's changing today

When a request to a generated echo server has a parameter that doesn't parse (e.g. a path parameter expecting an int but the client sent "foo"), the response currently looks like this:

HTTP/1.1 400 Bad Request

Invalid format for parameter id: parsing "foo" as int: strconv.ParseInt: parsing "foo": invalid syntax

Everything after the colon is whatever err.Error() happened to return — it comes from runtime.BindStyledParameterWithOptions / BindQueryParameterWithOptions and the underlying strconv / time parser. That text isn't part of any contract — it's whatever Go's standard library or oapi-codegen-runtime felt like saying at the time. Sending it on the wire means:

• API consumers can come to depend on its exact wording (and it can change between Go releases).
• It can leak internal-looking detail (struct field names from the runtime, package-private wording, etc.).
• Operators of pentest-conscious deployments end up writing custom middleware to strip it.

Why

Two reasons:

Security / info disclosure. Pentest reports routinely flag echoing raw err.Error() back to API callers as low-but-real info leakage. The current message can include Go stdlib parser internals (strconv.ParseInt: …), runtime/types implementation detail, or library-version-dependent wording. Each message in isolation looks innocuous, but the cumulative shape exposes how parameters get parsed server-side. Production-conscious teams currently have to fork or post-process this template to satisfy that finding — that's the whole reason we've maintained a local override for over a year.

More useful for the actual caller. When somebody sends id=foo, the helpful thing to tell them is "the value 'foo' didn't fit parameter id". The current message tells them which Go function failed and how, which is information for whoever wrote the server, not whoever is calling it. Quoting the offending value puts the response back in the API consumer's frame.

The original error isn't lost — it stays attached to the HTTPError (via SetInternal in v4 / Wrap in v5), so server-side error handlers still log it.

What it changes to

The same response becomes:

HTTP/1.1 400 Bad Request

Invalid format for parameter id: 'foo'

i.e. the value the caller actually sent. The original error is still attached to the echo HTTPError (via SetInternal(err) in v4 and Wrap(err) in v5), so server-side error handlers — including echo's default — still log the diagnostic. Just nothing leaks to the wire.

Concretely, the diff

In pkg/codegen/templates/echo/echo-wrappers.tmpl and pkg/codegen/templates/echo/v5/echo-wrappers.tmpl, four spots (path / query / header / cookie parameter binds) change from:

-return echo.NewHTTPError(http.StatusBadRequest, fmt.Sprintf("Invalid format for parameter X: %s", err))
+return echo.NewHTTPError(http.StatusBadRequest, fmt.Sprintf("Invalid format for parameter X: '%s'", <user-value>)).SetInternal(err)

<user-value> is the right input source for that location:

For pkg/codegen/templates/echo/v5/echo-wrappers.tmpl, .SetInternal(err) becomes .Wrap(err) (v5's equivalent — *echo.HTTPError doesn't have SetInternal, but it does have a Wrap(err) method that attaches an inner error).

What about the other framework templates?

Out of scope for this PR. The chi / gorilla / fiber / gin / iris / stdhttp templates have the same shape (http.Error(w, err.Error(), …)), and the same argument applies, but I want this PR to be small and easy to review. Happy to do those in follow-ups if this lands.

Why this is safe

• The HTTP status code is unchanged.
• The HTTP body shape is the same string template — only the substituted token changes.
• Server-side error handlers receive the same error (now via Internal / wrapped) so logging is unaffected.
• Valid traffic is byte-identical on the wire.

Tests

Regenerated all the affected test fixtures (internal/test/parameters/echo, internal/test/parameters/echov5, internal/test/strict-server/echo, the petstore-expanded examples). go test ./... is clean across the root, examples, and internal/test modules.

Background

We've shipped this as a local template override for over a year and it's surfaced no issues — the change is small, the contract is preserved, and the request/response shape is unchanged for valid traffic. Upstreaming so we don't have to maintain the override.