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
