fix(dev): respect forwarded proxy headers

[wangxpych]

Use the forwarded protocol in the Vite development server's Node request adapter so action requests behind an HTTPS reverse proxy retain their public scheme.

Keep the original Host header, which Vite validates against server.allowedHosts, instead of trusting a client-controlled forwarded host. Adds an HTTP-level regression test covering a valid forwarded protocol alongside a spoofed X-Forwarded-Host.

Closes #15454

[kdelay]

The dev server is not always behind a proxy, and trustProxy in 0.14.1 has no trust boundary: calling createRequest(req, res, { trustProxy: true }) directly, x-forwarded-host: evil.example.com, real.example.com yields http://evil.example.com/.

Vite's own host check reads only Host (isHostAllowed), so server.allowedHosts stops constraining the origin that throwIfPotentialCSRFAttack compares with Origin.

Could the forwarded host be validated against the resolved server.allowedHosts, or gated behind an opt-in? viteConfig is in scope at both call sites.

[wangxpych]

Good catch. I kept the Host header that Vite has already validated and only use proxy metadata for the forwarded protocol. The regression now sends X-Forwarded-Host: evil.example.com and verifies the request URL remains on the validated host.

Validated with all 10 @react-router/dev suites (188 tests / 184 snapshots), package typecheck, targeted ESLint, Prettier, and git diff --check.

[wangxpych]

Closing because I’m stepping back from maintaining this contribution. Thanks for your time.