Some REST endpoints are private to the WMF network. When we redirect (or link) between them, we need to base our links on the InternalServer setting, rather than the CanonicalServer setting. However, the same response from the same endpoint may in some cases contain both: references to private and public endpoints. Note also that responses may be cacheable, and shouldn't vary on which protocol was used to send the request.
This indicates that the code that constructs the target URL will need to know whether the target is public or private. The Router class should get an getPrivateRouteUrl() method, in addition to getRouteUrl().
This bug was caught when we ran roundtrip testing and all tests started to fail. But, the issue can be illustrated with this:
ssastry@scandium:~$ curl -x scandium.eqiad.wmnet:80 'http://en.wikipedia.org/w/rest.php/en.wikipedia.org/v3/page/html/Hospet' <!doctype html><title>Redirect</title><a href="https://en.wikipedia.org/w/rest.php/en.wikipedia.org/v3/page/html/Hospet/1087106448">https://en.wikipedia.org/w/rest.php/en.wikipedia.org/v3/page/html/Hospet/1087106448</a>
That request above uses scandium (which got the unreleased to-be-tested Parsoid code) as the proxy and you see that the http:// request gets redirected to a https:// url which now fails.
ssastry@scandium:~$ curl -x wtp1025.eqiad.wmnet:80 'http://en.wikipedia.org/w/rest.php/en.wikipedia.org/v3/page/html/Hospet' <!doctype html><title>Redirect</title><a href="http://en.wikipedia.org/w/rest.php/en.wikipedia.org/v3/page/html/Hospet/1087106448">http://en.wikipedia.org/w/rest.php/en.wikipedia.org/v3/page/html/Hospet/1087106448</a>
That request above is to wtp1025 (production cluster running released code from last train) which redirected the http:// req. to a http:// url