<div>I made a review in keystone that for this issue</div><div><a href="https://review.openstack.org/#/c/132235/">https://review.openstack.org/#/c/132235/</a></div><div>And I got solution from old heat solution - </div><div><a href="https://review.openstack.org/#/c/64142/">https://review.openstack.org/#/c/64142/</a></div><div> </div><div>I made it for keystone when we faced with problem that is described in the bug:</div><div><a href="https://bugs.launchpad.net/keystone/+bug/1370022">https://bugs.launchpad.net/keystone/+bug/1370022</a></div><div> </div><div>And I think that having a hardcoded entry in the config without right handling of proxies is not a good idea...</div><div> </div><div>Andrey.</div><div> </div><div> </div><div>03.03.2015, 20:33, "Miguel Grinberg" <miguel.s.grinberg@gmail.com>:</div><blockquote type="cite"><div>Ian, thanks for raising the issue here.<div> </div><div>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.</div><div> </div><div>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.</div><div> </div><div>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.</div><div> </div><div>Miguel </div></div><div><br /><div>On Tue, Mar 3, 2015 at 9:09 AM, Ian Cordasco <span><<a href="mailto:ian.cordasco@rackspace.com" target="_blank">ian.cordasco@rackspace.com</a>></span> wrote:<br /><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey all,<br /> <br /> It appears that currently a number of OpenStack services are not<br /> generating version catalogs correctly when the service sits behind a<br /> proxy. (Reference: <a href="https://bugs.launchpad.net/glance/+bug/1384379" target="_blank">https://bugs.launchpad.net/glance/+bug/1384379</a>) Glance<br /> already has a fix that was accepted for kilo-1 but it is suboptimal and<br /> assumes there’s only one proxy-address that will forward the request<br /> (which obviously is not true in every case).<br /> <br /> There exists RFC 7239 (<a href="http://tools.ietf.org/html/rfc7239" target="_blank">http://tools.ietf.org/html/rfc7239</a>) which is recent<br /> but defines a “Forwarded” header with explicit parameters that we should<br /> be using. There are also the defacto standards of X-Forwarded-By and<br /> X-Forwarded-Host that we should be inspecting as well.<br /> <br /> Currently, Glance’s solution is being copied over to other projects<br /> (Trove, Heat, Nova) and it is clearly suboptimal.<br /> <br /> I’m going to work on a more general solution for this, but if anyone can<br /> hammer one out faster, don’t be afraid to submit it. This is absolutely a<br /> bug that should be a high priority for us.<br /> <br /> Cheers,<br /> Ian<br /> <br /> __________________________________________________________________________<br /> OpenStack Development Mailing List (not for usage questions)<br /> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br /> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></blockquote></div></div>,<p>__________________________________________________________________________<br />OpenStack Development Mailing List (not for usage questions)<br />Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br /><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></p></blockquote>