Describe the feature
For deployment behind a reverse proxy one wants the receiving application to trust and use the X-Forwarded-For (and related) header set by the proxy. However, for edge deployments this is usually not desirable as they already provide the correct IP and attackers could provide false data in those headers. The runtime presets (node_*, bun, and deno) though are commonly deployed behind a reverse proxy and would thus benefit from an option to trust those headers and fill ServerRequest.ip with it's value.
A possible implementation would be to expose this as an environment variable like NITRO_TRUST_XFORWARDED=1 and/or a flag in defineConfig().
Cont'd from the discussion over at the h3 repo: h3js/h3#1366 (comment)
Additional information
Describe the feature
For deployment behind a reverse proxy one wants the receiving application to trust and use the
X-Forwarded-For(and related) header set by the proxy. However, for edge deployments this is usually not desirable as they already provide the correct IP and attackers could provide false data in those headers. The runtime presets (node_*,bun, anddeno) though are commonly deployed behind a reverse proxy and would thus benefit from an option to trust those headers and fillServerRequest.ipwith it's value.A possible implementation would be to expose this as an environment variable like
NITRO_TRUST_XFORWARDED=1and/or a flag indefineConfig().Cont'd from the discussion over at the h3 repo: h3js/h3#1366 (comment)
Additional information