Closes #1481

Problem

prepareResponse guarded header merging with !val.ok (src/response.ts:118), but Response.ok is false for all non-2xx statuses — not just errors. So prepared headers were dropped for intentional redirects and deliberate 4xx too:

app.get("/login-redirect", (event) => {
  setCookie(event, "sid", "1");
  return new Response(null, { status: 302, headers: { location: "/login" } });
});
// → set-cookie silently absent

return redirect(event, "/login") kept the cookie (it returns an HTTPResponse, which takes the merging path), so the two forms disagreed.

While confirming the report I found a second gap: event.res.errHeaders — the documented escape hatch for headers that must survive an error render, which handleCors writes to — was also dropped by this fast path. CORS headers survived a thrown 401 but vanished on a returned one:

302 set-cookie: null     ← reported bug
401 cors:      null      ← errHeaders dropped on returned 401
thrown cors:   *         ← errHeaders survive on thrown error

Fix

Scope the guard to error statuses and honor errHeaders there, matching what errorResponse() already does:

• < 400 — merge all prepared headers (fixes redirects/cookies; makes redirect() and a native 302 behave alike)
• >= 400 — merge only errHeaders (fixes CORS on a returned 401)

Success-only headers (caching, content negotiation, ...) still never leak into error responses, so #1228's intent is preserved. A custom error render returned from onError is still left untouched.

Behavior change

Returning a non-2xx Response no longer drops everything staged on event.res. Code that relied on event.res.headers being discarded for a 3xx will now see those headers on the response; error statuses are unchanged except that errHeaders are now applied.

Tests

Three regression tests in test/app.test.ts, all failing on main:

• redirect Response keeps setCookie
• error Response drops cache-control but keeps errHeaders
• returned and thrown 401 agree on CORS headers

Note on bundle size

The fix costs +19 bytes minified (+8 gzip), and both budgets were at their ceiling — defineHandler 6396→6415 against a 6400 limit, and H3Core 7281→7300 against a 7300 limit (i.e. passing with zero slack, which would have broken the next PR regardless). Raised to 6450/7350.

I tried hoisting the preparedRes read above the error branch to dedupe the kEventRes lookup and buy the bytes back; it came out a byte worse, so I reverted it. Happy to pay for the bytes elsewhere if you'd prefer the budgets held.

🤖 Generated with Claude Code

Summary by CodeRabbit

• Bug Fixes

  • Redirect responses now retain prepared headers, including cookies.
  • Error responses discard regular prepared headers while preserving explicitly configured error headers.
  • Returned and thrown HTTP errors now apply error headers consistently.

• Documentation

  • Clarified header behavior for success, redirect, and error responses.

• Tests

  • Added coverage for redirect cookies and error-header handling.