yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #57603
[Bug 1590608] Re: Services should use http_proxy_to_wsgi middleware
Reviewed: https://review.openstack.org/384311
Committed: https://git.openstack.org/cgit/openstack/ceilometer/commit/?id=30eb0f0ae16c7ffd0f90c3874d3cbc462d5863a0
Submitter: Jenkins
Branch: master
commit 30eb0f0ae16c7ffd0f90c3874d3cbc462d5863a0
Author: Juan Antonio Osorio Robles <jaosorior@xxxxxxxxxx>
Date: Mon Oct 10 09:42:04 2016 +0300
Add http_proxy_to_wsgi to api-paste
This sets up the HTTPProxyToWSGI middleware in front of Ceilometer. The
purpose of thise middleware is to set up the request URL correctly in
case there is a proxy (For instance, a loadbalancer such as HAProxy)
in front of Ceilometer.
So, for instance, when TLS connections are being terminated in the
proxy, and one tries to get the versions from the / resource of
Ceilometer, one will notice that the protocol is incorrect; It will show
'http' instead of 'https'. So this middleware handles such cases.
Thus helping Keystone discovery work correctly.
The HTTPProxyToWSGI is off by default and needs to be enabled via a
configuration value.
Change-Id: I24f16dda49bd9e7930ca9f0d32bf0793463aff03
Closes-Bug: #1590608
** Changed in: ceilometer
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1590608
Title:
Services should use http_proxy_to_wsgi middleware
Status in Aodh:
Fix Released
Status in Barbican:
New
Status in Ceilometer:
Fix Released
Status in Cinder:
Fix Released
Status in Glance:
Fix Released
Status in Gnocchi:
Fix Committed
Status in heat:
In Progress
Status in OpenStack Identity (keystone):
Fix Released
Status in neutron:
In Progress
Status in Panko:
In Progress
Status in OpenStack DBaaS (Trove):
In Progress
Bug description:
It's a common problem when putting a service behind a load balancer to
need to forward the Protocol and hosts of the original request so that
the receiving service can construct URLs to the loadbalancer and not
the private worker node.
Most services have implemented some form of secure_proxy_ssl_header =
HTTP_X_FORWARDED_PROTO handling however exactly how this is done is
dependent on the service.
oslo.middleware provides the http_proxy_to_wsgi middleware that
handles these headers and the newer RFC7239 forwarding header and
completely hides the problem from the service.
This middleware should be adopted by all services in preference to
their own HTTP_X_FORWARDED_PROTO handling.
To manage notifications about this bug go to:
https://bugs.launchpad.net/aodh/+bug/1590608/+subscriptions
References