<div dir="ltr">We (that is, the cores, contributors, and consumers that I've been collaborating with over the past year on this) came to the consensus that leaving the cors middleware as generic & configurable as possible was preferable, and that an openstack-specific version that automatically initializes itself from keystone's service catalog and trusted dashboards might be a next step. I'm sure the oslo core team can chime in, but the arguments that I recall were:<br><br>1- Maintaining a list of headers in a repository separate from projects that use them is undesirable and likely to bitrot.<br>2- Oslo's backwards-compatibility policy means that new and/or modified headers could only be added, not removed. This would result in a long list of no-longer used headers (<a href="https://tools.ietf.org/html/rfc6648">https://tools.ietf.org/html/rfc6648</a> was mentioned).<br>3- We could not guarantee that downstream consumers of the CORS middleware don't already exist, and they should not be subject to having suddenly-approved headers.<br><br>We'd like to move forward with this approach at this time, to ensure that CORS is consistently enabled in Mitaka before the freeze. I'd be happy to work with you on alternative approaches moving forwards; for example, I think teaching oslo's genconfig to permit project-specific default overrides would solve this problem in a way that would make both of us, and other users of genconfig, very happy.<div><br></div><div>Michael</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Feb 17, 2016 at 5:08 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">A set of CORS patches came out recently that add a ton of content to<br>
paste.ini for every project (much of it the same between projects) -<br>
<a href="https://review.openstack.org/#/c/265415/1" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/265415/1</a><br>
<br>
paste.ini is in a really weird space because it's config, ops can change<br>
it, so large amounts of complicated things in there which may change in<br>
future releases is really problematic. Deprecating content out of there<br>
turns into a giant challenge because of this. As does changes to code<br>
which make any assumption what so ever about other content in that file.<br>
<br>
Why weren't these options included as sane defaults in the base cors<br>
middleware?<br>
<br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" rel="noreferrer" target="_blank">http://dague.net</a><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div>