Submitter: Jenkins
Branch:    master

commit 19c354aacd27f6941467e34826774c6199bc4f8f
Author: Juan Antonio Osorio Robles <>
Date:   Mon Oct 10 08:56:12 2016 +0300

    Add http_proxy_to_wsgi to api-paste
    This sets up the HTTPProxyToWSGI middleware in front of Neutron-API. The
    purpose of this 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 Neutron.
    So, for instance, when TLS connections are being terminated in the
    proxy, and one tries to get the versions from the / resource of
    Neutron, 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: Ice9ee8f4e04050271d59858f92034c230325718b
    Closes-Bug: #1590608

** Changed in: neutron
       Status: In Progress => Fix Released

You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.

  Services should use http_proxy_to_wsgi middleware

Status in Aodh:
  Fix Released
Status in Barbican:
  In Progress
Status in Ceilometer:
  Fix Released
Status in Cinder:
  Fix Released
Status in cloudkitty:
  In Progress
Status in congress:
Status in Freezer:
  In Progress
Status in Glance:
  Fix Released
Status in Gnocchi:
  Fix Committed
Status in heat:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in Magnum:
Status in neutron:
  Fix Released
Status in Panko:
  Fix Released
Status in OpenStack Search (Searchlight):
  In Progress
Status in senlin:
  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:

Mailing list:
Post to     :
Unsubscribe :
More help   :

Reply via email to