<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Feb 18, 2016 at 9:58 AM Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Here is the future we're going to have.<br></blockquote><div><br></div><div>The future is only going to happen if help materializes. So far, we still need updated patches on all 22 projects, and these will need to land in time for the mitaka release. I can commit to doing about 5 of them given my other obligations, and I need help for the rest.</div><div><br></div><div>Who is willing to help?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Right now, it appears that the default in the middleware is do nothing.<br>
That means CORS won't be in a functional state on services by default.<br>
However, I thought the point of the effort was that all the APIs in the<br>
wild would be CORS enabled.<br></blockquote><div><br></div>This is by design, and is specifically called out in the cross-project specification, adopted on June 9th.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><a href="http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html">http://specs.openstack.org/openstack/openstack-specs/specs/cors-support.html</a></div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not hugely sympathetic to defaulting to not having the Keystone<br>
headers specified in the non keystone case. I get there are non keystone<br>
cases, but keystone is defcore. Making the keystone case worse for the<br>
non keystone case seems like fundamentally the wrong tradeoff.<br></blockquote><div><br></div><div>The non-keystone use cases is also mentioned in the spec.</div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Michael</div></div>