On 09/23/2015 07:36 AM, Julien Danjou wrote: > On Wed, Sep 23 2015, Sean Dague wrote: > >> Does that solution work in the HA Proxy case where there is one >> terminating address for multiple backend servers? > > Yep.
Ok, how exactly does that work? Because it seems like oslo_middleware.ssl is only changing the protocol if the proxy sets it. But the host in the urls will still be the individual host, which isn't the proxy hostname/ip. Sorry if I'm being daft here, just want to understand how that flow ends up working. >> Because there is the concern that this impacts not only the Location >> header, but the link documents inside the responses which clients are >> expected to be able to link.follow. This is an honest question, I >> don't know how the oslo_middleware.ssl acts in these cases. And HA >> Proxy 1 to N mapping is very common deployment model. > > It should, but some project like Keystone does not handle that > correctly. I just submitted a patch that fixes this kind of thing by > using correctly the WSGI environment variable to build a correct URL. > That fixes also the use cases where Keystone does not run on / but on > e.g. /identity (the bug I initially wanted to fix). > > https://review.openstack.org/#/c/226464/ > > If you use `wsgiref.util.application_uri(environment)' it should do > everything correctly. With the SSL middleware enabled that Mathieu > talked about, it will translate correctly http to https too. Will that cover the case of webob's request.application_uri? If so I think that covers the REST documents in at least Nova (one good data point, and one that I know has been copied around). At least as far as the protocol is concerned, it's still got a potential url issue. > The {public,admin}_endpoint are only useful in the case where you map > http://myproxy/identity -> http://mykeystone/ using a proxy > > Because the prefix is not passed to Keystone. If you map 1:1 the path > part, we could also leverage X-Forwarded-Host and X-Forwarded-Port to > avoid having {public,admin}_endpoint options. It also looks like there are new standards for Forwarded headers, so the middleware should probably support those as well. http://tools.ietf.org/html/rfc7239. -Sean -- Sean Dague http://dague.net
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ 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