take x-forwarded-headers into account when proxying to a connect-based app #275

gonsfx opened this Issue May 4, 2011 · 5 comments


None yet

4 participants


When proxying to a connect-based app by apache/nginx/squid or any other kind of proxy that sets x-forwarded-headers (albeit the shortcomings of this approach often done because of hosting restrictions), middleware that is based on req.headers.host, req.socket.remoteAddress and probably others is working on proxy-related data instead of data related to the originating request.

logging :remote-addr with connect-logger will log the proxys ip address, redirecting to '/' will redirect to the proxys hostname (localhost: when running on same machine as node) and probably other problems will also occur (which i haven't found yet).

Offering a middleware layer that would typically be invoked early on in the middleware chain and would check for the existance of x-forwarded-headers and replace req properties concealed by proxying with its x-forwarded-counterparts would be handy.

Sencha Labs member
tj commented May 4, 2011

yeah we could certainly implement this as middleware


There is a third-party middleware that does this: https://github.com/bartt/trust-reverse-proxy


That one is used to check if a trusted proxy has forwarded the request as opposed to an untrusted one which is a nice concept in itself - but it does neither change req.headers.host nor req.socket.remoteAddress


Suits my own purposes quite well. Constructive Criticism, anyone?

Sencha Labs member
tj commented May 9, 2011

cool man, feel free to chuck a link up in the wiki

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment