Include X-Forwarded-Host when proxying and rewriting Host in Workhorse
What does this MR do and why?
The upstream will never be aware it's being proxied under a different Host otherwise if X-Forwarded-Host is not included, which is necessary in cases like constructed absolute redirects in Rails for example.
This is causing #357828 (closed) where Rails is trying to redirect to the target URL, but the client's Host is different.
We've added rewriting this Host header as part of !83550 (merged), however the proper solution should also include the original Host as X-Forwarded-Host.
This is essentially the before/after outcome:
# before !83550
root@cat-geo-secondary-gitlab-rails-1:~# curl http://primary.geo-gitlab-test.ml -H "Host: secondary.geo-gitlab-test.ml" -s -i | grep -i location
location: http://secondary.geo-gitlab-test.ml/users/sign_in
# after !83550; before this MR
root@cat-geo-secondary-gitlab-rails-1:~# curl http://primary.geo-gitlab-test.ml -H "Host: primary.geo-gitlab-test.ml" -s -i | grep -i location
location: http://primary.geo-gitlab-test.ml/users/sign_in
# after this MR
root@cat-geo-secondary-gitlab-rails-1:~# curl http://primary.geo-gitlab-test.ml -H "Host: primary.geo-gitlab-test.ml" -H "X-Forwarded-Host: secondary.geo-gitlab.test.ml" -s -i | grep -i location
location: http://secondary.geo-gitlab.test.ml/users/sign_in
The why behind why we need to overwrite the Host header in the first place is described in #339260 (closed), but essentially, some load balancers/reverse proxies won't recognize the different Host when accessing an URL, which is why we initially added !83550 (merged).
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.