OptimalBits/redbird — pull request #5 by tcoats (2014-10-02 12:50:46+00:00)
Title: Host headers as registered are passed through to the target

When proxying to a server running nginx or apache host headers are needed to make sure the webserver selects the correct website. http-proxy simply passes on the current request object, and passes through a host header that matches the `source`.

If I'm pulling together an existing, legacy api into a new url structure I want the ability to set the host header to the `target`. e.g.

```js
proxy.register('api.awesomecompany.com/legacy/v0', 'http://awesomecompany.com/api/cgi-bin/FOO/BAR');
```

The server that responds to awesomecompany.com (the target) also serves up other subdomains and the website notsoawesomecompany.com. It needs the target host header `awesomecompany.com` so it knows what website to serve. The existing redbird / http-proxy code just passes on the `source` host header. So a request is made to the webserver hosting `awesomecompany.com` for the host header `api.awesomecompany.com`. The DNS entry for `api.awesomecompany.com` does not point to the target server and the target server doesn't know what to do with the request. As a result I suggest using the target host for the host header, as implemented in this pull request.

However I imagine that you might want your target to know the `actual` host header it's handling, you might want it to believe it's the real server. You can get the original host and port through the `x-forwarded-` header entries, but that might not be enough for some situations.

It would be interesting to have some discussion about this. I think host header proxying is very useful for my use case and does not impact many other use cases such as direct IP and port proxying.