Resolves #1479.

Problem

In toResponse, only typeof r === "number" rejections were special-cased into an HTTPError. Every other non-Error rejection value re-entered toResponse as if it were a normal handler return value, so it was rendered as a successful response body:

app.get("/boom", () => {
  throw { status: 400, secret: "db-password" };
});
// before → 200 {"status":400,"secret":"db-password"}

Note the status: 400 was never honored — it was just a field in a 200 body. Same for throw "not-an-error" (200 with the string as body) and throw undefined (200, empty). A caught-and-rethrown non-Error from a DB driver or third-party lib leaked its full contents to the client with a success status, and onError / unhandled logging never saw it.

Fix

A toError() normalizer applied at both throw-handling sites — the promise rejection path in toResponse, and the synchronous catch in handlerWithFetch, which had the same shape.

Two rules:

1. A valid status is deliberate shorthand. throw { status: 404 } is the object form of throw 404 from feat(error): coerce thrown number/string to HTTPError #1372, so it renders identically and is not reported as unhandled. An invalid or out-of-range status is more likely a mistake than intent, so it falls back to a logged 500 rather than quietly becoming the shorthand.
2. Only the status is ever inherited. message, data, statusText and headers are dropped; the original value is kept as cause, which is never serialized. So the leak is closed on both paths.

The status is read explicitly off the value rather than passed to the HTTPError constructor as cause. That matters: the constructor deliberately falls back to cause.status / cause.statusText / cause.headers (tested at test/errors.test.ts — "can inherit deprecated statusCode/statusMessage from cause"), which is right for an Error the app built, but would let an arbitrary thrown object forge the status text and response headers. There are regression tests for both.

kHandled / kNotFound are passed through: callNodeHandler deliberately does reject(kHandled) on a Node stream error, and without the passthrough a JSON error body gets appended to an already-streamed response.

Incidental: sanitizeStatusCode hardening

Honoring a caller-supplied status routes untrusted input into sanitizeStatusCode, which turned out to range-check without first confirming it held a number. Comparisons against an object are all false, so it returned the object itself, after which new Response threw init["status"] must be in the range of 200 to 599 — the exact leak its own comment warns about. [500] likewise returned the array.

Number.isInteger closes objects, arrays, floats and NaN in one check. This is a shared helper used well beyond this path, so it's the highest-risk part of the diff despite being three lines: floats like 400.5 and array-ish values now fall back to the default instead of being coerced downstream.

Tests

New non-Error throws block in test/errors.test.ts, across the web/node matrix:

• object / async object / string / undefined no longer render as a body
• explicit status and deprecated statusCode are honored
• invalid statuses (999, -1, 0, "abc", NaN, null, an object) fall back to 500
• a thrown object cannot forge statusText or response headers
• throw { status: 404 } renders identically to throw 404 (asserted against each other, not a hardcoded body, so it stays pinned to the feat(error): coerce thrown number/string to HTTPError #1372 feature)
• onError receives the wrapped error with cause intact
• a cross-realm Error is not rendered as a body — toError must use the same instanceof Error check as prepareResponse; a broader one (e.g. Error.isError) would pass it through only for prepareResponse to reject it and render it as a body again. This was a pre-existing 200 leak that the fix also closes.

Note on bundle size

Thresholds needed bumping: H3 18_100→18_300 (gzip 6_850→6_950), H3Core 7_350→7_500, defineHandler 6_450→6_650 (gzip 2_600→2_700). Actuals are 18231/6898, 7460/2957, 6578/2642. Happy to golf toError smaller if the cost is a concern.

Behavior change worth flagging

A third-party object that happens to carry .status — e.g. { status: 403, code: "AccessDenied", requestId } from an AWS-style client — now returns a silent 403 with no log trace. Nothing leaks (code / requestId are dropped), but #1479's "logging never sees it" complaint still applies to that specific shape. h3 can't distinguish it from a deliberate throw { status: 403 }, and this PR chose consistency with the #1372 shorthand. Flagging it since it's a judgement call, not a forced one.

🤖 Generated with Claude Code