Description of problem:

tl;dr: If a GET request to `alias1.com/abc` yields a redirect response with `Location` header `alias2.com/xyz` from my app running on OpenShift (where `alias2.com` and `alias2.com` are both custom aliases for the OpenShift application host), it seems that OpenShift rewrites the `Location` response header on its way out such that its value becomes `alias1.com/xyz`. I need the `Location` header to go back to the client unchanged.

-----

I am running a Rails app as an OpenShift application. I have the application configured the OpenShift application to have two custom aliases — let's call them `example.com` and `ex.co`.

The primary purpose of the app is to serve as a CMS for various articles; a secondary function is a short-link redirect service. For any article in the CMS, it has a long URL such as `example.com/the-article-slug` and a short URL such as `ex.co/JKL`.

The routing rules in my Rails app are set up such that if an incoming request specifies a `Host` of `ex.co`, then it routes the request to the short-link redirect controller. (If the host for the request is anything other than `ex.co`, then the request is routed to a typical controller, which finds an article and serves it.) The short-link redirect controller inspects the URL path, looks up the corresponding long URL, and sends a `Location` response header with that long URL, which, as I mentioned before, involves the hostname `example.com`.

In other words, I have a single Rails app that is set up so that a request to `ex.co/JKL` should redirect the browser to `example.com/the-article-slug`.

Unfortunately, it seems that OpenShift is doing something "smart" and is rewriting this outbound `Location` header on the fly, replacing `example.com` with `ex.co`. Thus, what I'm seeing is that a request for `ex.co/JKL` will receive a response redirecting the browser to `ex.co/the-article-slug`. But a request to this new URL gets routed to my short-link redirect service, and this service doesn't recognize `/the-article-slug` as a valid short link code, so it yields a 404 error.

(My guess is that there's some sort of on-the-fly rewrite on outbound HTTP headers whose logic is something like "if there's a redirect to an external host, then pass the Location through, but if there's an 'internal redirect', then make sure the hostname of the redirect URL matches that of the previous request so cookies, SSL, and users don't get confused" — where a redirect is "internal" if the target hostname matches the canonical hostname or one if its aliases. If this is indeed the case, unfortunately, as you can see, this isn't a safeguard that I want enforced in my case.)

At any rate, I was hoping you could do something to remedy this situation. I was wondering whether it's possible to expose a settings control that would allow me to disable this redirect rewriting behavior. Or perhaps I could send the redirect using some special `X-Real-Location` header so that you guys know I *really* do want to redirect to this other hostname which happens to be an alias for this application. Or perhaps you could suggest a workaround that I may not be aware of?

Version-Release number of selected component (if applicable):


How reproducible:

This incorrect redirect behavior is consistent.

Steps to Reproduce:
1. Create a new OpenShift application (with the Ruby stack).
2. Configure the application to have two custom aliases, e.g. `a.com` and `b.com`.
3. Set up a web app (e.g. Rails).
4. Bonus: Configure the web app to be hostname-sensitive such that, for instance, a request for URL `/abc` is unrecognized by the app request router if the `Host` request header is something other than `a.com` and the URL `/xyz` is only recognized if the `Host` is `b.com`.
5. Configure the web app so that for a request to `a.com/abc`, it sends a 30x redirect response with Location header `b.com/xyz`.
6. Make an HTTP GET request for `a.com/abc`.
7. Inspect the HTTP response message for the Location header.

Actual results:

The `Location` HTTP response header will be `http://a.com/xyz`.

(If you did the optional step 4 above, when you try to do step 6 in a browser, the browser will receive a 404 error.)

Expected results:

The *desired* `Location` header value is `http://b.com/xyz`.

(If you did the optional step 4, the correct browser behavior is to see a 200 response with the payload corresponding to `b.com/xyz`.)

Additional info: