Two bugs made `wscat ws://host/v1/responses` fail with
"Transfer-Encoding can't be present with Content-Length":
1. authz/management policy 401'd the proxy's own internal authenticate/prepare
loopback call to /api/internal/codex-responses-ws (MANAGEMENT-classified, the
per-process bridge secret wasn't recognized one layer up). Added a tightly-scoped
carve-out: isValidWsBridgeRequest() honors a timing-safe sha256 match of
OMNIROUTE_WS_BRIDGE_SECRET (x-omniroute-ws-bridge-secret header) for that exact
internal path; the route still re-validates the secret. → auth now succeeds → 101.
2. On auth failure the proxy spread the internal fetch's response headers onto the
raw upgrade socket — a chunked Transfer-Encoding + Next CSP/route-class headers
collided with writeHttpError's Content-Length framing (and duplicated Content-Type
via a case-mismatched spread). writeHttpError now strips framing + pipeline/security
headers (case-insensitive), and the auth-fail callsite no longer forwards them.
Regression test: tests/unit/responses-ws-proxy-headers.test.mjs (exports writeHttpError;
asserts no TE+CL, single Content-Type, no CSP/route-class leak, safe headers forwarded).
- Move wreq-js and tls-client-node to optionalDependencies
- Lazy-load wreq-js WS proxy with graceful 503 when unavailable
- Auto-detect Android platform for headless mode (no browser open)
- Set GYP_DEFINES for better-sqlite3 build on Android/ARM
- Extended build timeout to 600s for ARM compilation
- Skip wreq-js binary fix on Android (unsupported platform)
- Platform warnings for unsupported features (WS proxy, TLS, Electron, MITM)
Co-authored-by: t-way666 <t-way666@users.noreply.github.com>
