Handling of URL-rewriting proxies

Current situation

The observer service does not recognize situations where the orchestrator is installed behind a reverse proxy that performs URL-rewriting or TLS termination. The header links it generates hence refer to the 'internal' URL, not the exposed one.

For example, if the service is accessed through https://my_orchestrator.example.com/foobar/workflows/xxx/status, the generated links may be http://my_orchestrator.example.com/workflows/xxx/status, which is not correct.

Desired outcome

The observer service (and other similar ones) should handle that situation in a proper way.

Analysis

The orchestrator could use the X-Forwarded- headers, if instructed to do so (it should not be the default behavior, as it is subject to data injection if the headers are faked.

It could also implement a 'fallback' method, specifiying a endpoint root to use (for example OPENTF_{service_}BASE_URL=https://my_orchestrator.example.com/foobar).