On 09/24/2015 03:40 AM, Julien Danjou wrote: > 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. :)
It's also a pretty serious change in document content. We've been returning absolute URLs forever, so assuming that all the client code out there would work with relative code is a really big assumption. That's a major API bump for sure. And it seems like we have enough pieces here to get something better with the proxy headers (which could happen early in Mitaka) and to fill in the remaining bits if we clean up the service catalogue use. -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