v0.7.4 — CORS pass-through for browser-facing deployments
v0.7.4 makes wavefront usable as a browser-facing gateway. A cross-origin SPA
call carrying Authorization triggers a CORS preflight, and wavefront had no CORS
handling: the OPTIONS preflight 404'd as an unbound route, and proxied responses
dropped the upstream's Access-Control-* headers — so every cross-origin browser
call through the gateway was blocked.
-
CORS pass-through (the upstream owns CORS). wavefront does not own CORS;
the upstream is the single source of truth. A preflight — OPTIONS with Origin
and Access-Control-Request-Method — is forwarded to the default upstream and
its response relayed, bypassing routing, negotiation, and the codec, so it no
longer 404s. On a proxied response, the upstream's Access-Control-* and Vary
headers are carried through verbatim, on every response derived from an
upstream reply: success, 204/205, declared error, the aid envelope, and the
capability-ceiling 502. Origin already reaches the upstream as a forwarded
client header, so it echoes the correct allow-origin. No new configuration or
dependencies — the allowed-origins list stays in the backend (#147).Deliberate gap: a wavefront-originated response synthesized before any upstream
call (unsupported_contract_version, unknown_route, unsupported_media_type) has
no upstream CORS to mirror and carries none. Those are misconfigured-request /
development conditions, not the normal browser flow. -
feat: forward CORS preflights and relay upstream Access-Control-* (#148)