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.
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?
cool man, feel free to chuck a link up in the wiki