← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1590608] Re: Services should use http_proxy_to_wsgi middleware

 

Reviewed:  https://review.openstack.org/326798
Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=b0d0b1d0ba7b9d1fadca0e7932c5886bc6cc7825
Submitter: Jenkins
Branch:    master

commit b0d0b1d0ba7b9d1fadca0e7932c5886bc6cc7825
Author: Jamie Lennox <jamielennox@xxxxxxxxx>
Date:   Wed Jun 8 11:59:09 2016 +1000

    Use http-proxy-to-wsgi middleware from oslo.middleware
    
    The HTTP_X_FORWARDED_PROTO handling fails to handle the case of
    redirecting the /v1 request to /v1/ because it is handled purely by
    routes and does not enter the glance wsgi code. This means a https
    request is redirect to http and fails.
    
    oslo.middleware has middleware for handling the X-Forwarded-Proto header
    in a standard way so that services don't have to and so we should use
    that instead of our own mechanism.
    
    Leaving the existing header handling around until removal should not be
    a problem as the worst that will happen is it overwrites an existing
    'https' header value set by the middleware.
    
    Closes-Bug: #1558683
    Closes-Bug: #1590608
    Change-Id: I481d88020b6e8420ce4b9072dd30ec82fe3fb4f7


** Changed in: glance
       Status: New => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1590608

Title:
  Services should use http_proxy_to_wsgi middleware

Status in Barbican:
  New
Status in Cinder:
  New
Status in Glance:
  Fix Released
Status in OpenStack Identity (keystone):
  In Progress
Status in OpenStack DBaaS (Trove):
  New

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/barbican/+bug/1590608/+subscriptions


References