f93c2fb5f1
The endpoint field in the info payload is intended to help the javascript web code find out where the API endpoint is, and to allow people who are deploying html/js as static assets to an external web server drop a json file in that deployment to tell it where their zuul-web server is. The only scenario where the endpoint information as served by the /info or /{tenant}/info endpoints of zuul-web is useful is same-host/single-apache deployments that are hosted on a sub-url ... and unfortunately, it's not possible for the aiohttp code to be aware of such suburl deployments from http headers. request.url has the actual location (such as http://localhost:8080/info) and X-Forwarded-Host will only contain the host, not the path. The actual important aspects of the payload are: * A payload always be able to be found no matter the deployment scenario. * That a deployer can communicate to the javascript code the root of the REST API in the scenarios where relative paths will resolve to the incorrect thing. With that in mind, change the Info.endpoint field returned by zuul-web to default to None (or actually json null), or to a value provided by the deployer in the zuul.conf file similar to websocket_url. This way the web app can view 'null' as meaning "I'm deployed in such a manner that relative paths are the correct thing to fetch from" and a value as "the deployer has told me explicitly where to fetch from, I will join my relative paths to the value first." Because it is a value that is provided by the deployer if it is to exist, rename it to "rest_api_url" to better match websocket_url and stats_url. Change-Id: I6b85a93db6c70c997bbff1329373fbfc2d1007c6 |
||
---|---|---|
.. | ||
static | ||
__init__.py | ||
handler.py |