v1.61.1 - Apply CORS to final responses

[1.61.1] - 2026-06-22 — Wezen

Theme: CORS on every response. The framework applied CORS headers only to the OPTIONS preflight, so cross-origin regular responses — and especially error/exception responses (422, 401, …) — shipped without Access-Control-Allow-Origin, and browsers withheld the body. A separately-served frontend (e.g. a Vite dev SPA on another origin) calling the API would therefore get an empty/unreadable body for any validation or error response. Application::handle() now applies CORS to the final response — in both the dispatch and exception-handler branches — so the headers that were always intended for these responses are actually present. Patch release — bugfix, no new env, no migrations, no action required.

Fixed

• Cross-origin error/regular responses are now readable. Application::handle() applies CORS headers to the final response in both the normal and exception-handler branches, so a cross-origin client (e.g. a dev SPA on a different origin) can read the body of a 422/401/etc. Previously only the OPTIONS preflight carried CORS headers, leaving regular and error response bodies blocked by the browser. Same-origin requests and disallowed origins are unaffected.

Added

• Cors::applyToResponse(Request, Response) (supporting the fix above). Applies the regular-request CORS headers (Access-Control-Allow-Origin, Vary: Origin, plus Access-Control-Expose-Headers / Access-Control-Allow-Credentials per config) to an already-built response. No-op when there is no Origin, the origin is not allowed, or the header is already set (e.g. a preflight response), so it never clobbers the router's preflight handling.