On Thu, Sep 24 2015, Jamie Lennox wrote: Hi Jamie,
> So this is a long thread and i may have missed something in it, > however this exact topic came up as a blocker on a devstack patch to > get TLS testing in the gate with HAproxy. > > The long term solution we had come up with (but granted not proposed > anywhere public) is that we should transition services to use relative > links. This would be a good solution too indeed, but I'm not sure it's *always* doable. > As far as i'm aware this is only a problem within the services > themselves as the URL they receive is not what was actually requested > if it went via HAproxy. It is not a problem with interservice requests > because they should get URLs from the service catalog (or otherwise > not display them to the user). Which means that this generally affects > the version discovery page, and "links" from resources to like a next, > prev, and base url. Yes, but what we were saying is that this is fixable by using HTTP headers that the proxy set, and translating them to a correct WSGI environment. Basically, that will make think WSGI that it's a front-end, so it'll build URL correctly for the outer world. > Is there a reason we can't transition this to use a relative URL > possibly with a django style WEBROOT so that a discovery response > returned /v2.0 and /v3 rather than the fully qualified URL and the > clients be smart enough to figure this out? We definitely can do that, but there is still a use case that would not be covered without a configuration somewhere which is: e.g. http://foobar/myservice/v3 -> http://myservice/v3 If you return an absolute /v3, it won't work. :) -- Julien Danjou // Free Software hacker // http://julien.danjou.info
signature.asc
Description: PGP 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
