I get that, but it makes things very difficult for our (Netlify and Discourse) common customers.
We need to tell customers with proxies in front of their Discourse installation to scrub certain headers from requests before they forward them to us and we really don’t want that list to grow.
Would you consider adding support for the industry standard x-forwarded-for or the sort-of-emerging true-client-ip?
EDIT: we’ve adjusted how we’re doing things such that this is not a huge problem for us
Great to hear! We use x-forwarded-for internally, so no can do on that one. Could you link me to the details on the “emerging standard” you reference? Our team would be happy to take a look at it, I just hadn’t heard of it before so not sure where you’ve seen it
Seems event.headers['client-ip'] has started to be undefined some time this week. I still could not find any documentation on X-Nf-Client-Connection-Ip via Google, but fortunately this thread appeared.On the other hand, event.headers['X-Nf-Client-Connection-Ip'] is also undefined for me right now, so not sure how to proceed…
Update: Seems using lowercase event.headers['x-nf-client-connection-ip'] works for now.
Old thread, but something I wanted to note: ‘client-ip’ works when hosting locally with netlify dev from the CLI. In that case, though, ’ x-nf-client-connection-ip’ does not. However, once deployed to web, ‘client-ip’ does not work and ’ x-nf-client-connection-ip’ does.
I don’t believe CLI can have x-nf- headers, as those are something added by Netlify servers. Since the request is not going through Netlify servers, maybe adding that would not be ideal - but I see your complaint. Mind filing an issue on the CLI repo so the devs can decide what’s the best path forward?