Researching in order to understand this bug I found that there is another header that could be handy: X-Forwarded-Proto, which contains the protocol used before the proxy removed the ssh thing (in this case is 'https').
So if the webob.Request instance is modified in order to use this schema instead of the one defined by Heat API, the call to webob.Request.relative_url() will return a URL with the correct schema.
I think that the X-Forwarded-For won't be needed, because webob uses the env(HTTP_HOST) to create a URL in webob.Request.relative_url(), and that environment variable is the same that comes in X-Forwarded-For.
This modification could be done in heat.api.openstack.v1.util.make_url() or a new middleware could be added in order to alter the request. Any though about the best place to implement the change?
Researching in order to understand this bug I found that there is another header that could be handy: X-Forwarded-Proto, which contains the protocol used before the proxy removed the ssh thing (in this case is 'https'). relative_ url() will return a URL with the correct schema. relative_ url(), and that environment variable is the same that comes in X-Forwarded-For. openstack. v1.util. make_url( ) or a new middleware could be added in order to alter the request. Any though about the best place to implement the change?
So if the webob.Request instance is modified in order to use this schema instead of the one defined by Heat API, the call to webob.Request.
I think that the X-Forwarded-For won't be needed, because webob uses the env(HTTP_HOST) to create a URL in webob.Request.
This modification could be done in heat.api.