Forward IP to `Request`

[QuiiBz]

In both CLI and Serverless, there is no way to get the user's IP. We should inject it as a header to each Request. Not sure what's the proper header name to use for this, maybe X-Real-IP?

[cyco130]

Here's how some other runtimes and deployment platforms handle this:

• Cloudflare Workers: Available in CF-Connecting-IP header
• Deno: Passes as a second argument (connInfo) that contains a remoteAddr property
• Netlify Edge: Passes as a second argument (info) that contains an ip property
• Netlify Serverless: Available in X-Nf-Client-Connection-IP header
• Vercel Edge: Available in X-Forwarded-For header

HatTip uses the following convention for Node and Vercel Serverless:

• req.ip if available (Express etc. use this)
• X-Forwarded-For header if available
• req.socket.remoteAddress

For Bun, currently it only uses X-Forwarded-For.

Personally I'd recommend using either the X-Forwarded-For header which is non-standard but commonly used, or the by directive of the Forwarded header which is standard but quite uncommon.

But you may also consider passing a second parameter to the handler function like many of them do. Possible use cases:

• IP address and other connection info
• Environment variables/secrets
• Cloudflare Workers has waitUntil that signals the runtime to wait for a promise before shutting down the worker (relic of service worker API I guess)
• Platform-specific features like Cloudflare Workers' KV store, Durable Objects etc.

[QuiiBz]

Thanks for the investigation! It's interesting to see how other runtimes handle it and makes me think that (maybe) it should be standardized with WinterCG?

I do prefer the idea of having a header to grab the IP, since it's the most logical one: Request contains all information about a request, and the IPs of the client/proxies are also commonly transferred through the headers. X-Forwarded-For seems to be heavily used compared to Forwarded / X-Real-IP so it should be the most logical one to use.

About passing a second parameter to the handler, it doesn't have any use cases now or in the future. We plan to use the global Lagon object to access more specific APIs.