Feature request: Add ability to map external vanity URL(s) to internal service URL(s) based on the context.

[anokun7]

In some use cases, applications may not want to reveal the internal service specific URL that maps to the containers. The service URL would be hidden under a vanity URL and through URL rewriting, the request would be routed to the specific set of containers through interlock/nginx, based on the context path following the URL/domain. Without this layer, users would need to configure an additional reverse proxy layer over and in from on nginx to perform the URL rewriting & redirection.

For eg:
End users would use a url like http://app.example.com/v1/service. This would get mapped to http://app.configuration.example.com/v1/service​.
The logic would be that the /v1/service context path would be mapped to the configuration service at /v1/service. Both app.example.com & app.configuration.example.com would point to the same ip address.

Another end point similarly say /v1/info would be mapped to text at /v1/info. So end users would use http://app.example.com/v1/info and get redirected to http://app.text.example.com/v1/info.

At the ​same time this would need to allow a default catch-all URL for all other requests: http://app.example.com/v1/ should map to http://app.dit.web.example.com/v1/ for example.

[ehazlett]

This seems like a very very specific use case. You should be able to just add an "alias domain" and not try to hack the context root. I haven't seen any other use case where someone mangles the host name based upon a path.