Ian, thanks for raising the issue here. The X-Forwarded headers are the standard way to deal with URLs for services behind proxies. I already commented on the Heat proposal to that effect, I think that is the proper way to support services behind proxies.
Now in our case, there is also another source of external URLs, the keystone catalog. One can assume the catalog has the externally visible URL under PUBLIC_URL, so I would like to suggest that if the X-Forwarded headers aren't present, the catalog would be a good second source. I think having a hardcoded entry in the config (as the glance merged patch does) is not a bad idea as an override for special situations, but I really see no need for that to be the only solution to this problem. Web applications have been working behind proxies using the X-Forwarded headers for a long time, it's a nice and proven solution, in my opinion. Miguel On Tue, Mar 3, 2015 at 9:09 AM, Ian Cordasco <ian.corda...@rackspace.com> wrote: > Hey all, > > It appears that currently a number of OpenStack services are not > generating version catalogs correctly when the service sits behind a > proxy. (Reference: https://bugs.launchpad.net/glance/+bug/1384379) Glance > already has a fix that was accepted for kilo-1 but it is suboptimal and > assumes there’s only one proxy-address that will forward the request > (which obviously is not true in every case). > > There exists RFC 7239 (http://tools.ietf.org/html/rfc7239) which is recent > but defines a “Forwarded” header with explicit parameters that we should > be using. There are also the defacto standards of X-Forwarded-By and > X-Forwarded-Host that we should be inspecting as well. > > Currently, Glance’s solution is being copied over to other projects > (Trove, Heat, Nova) and it is clearly suboptimal. > > I’m going to work on a more general solution for this, but if anyone can > hammer one out faster, don’t be afraid to submit it. This is absolutely a > bug that should be a high priority for us. > > Cheers, > Ian > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev