Feature: Use CORS headers for whitelisting (as an alternative to regex strings)

[turquoiseowl]

Suppose we have the following at http://slave.com/proxy.html:

<script src="xdomain.js" master="http://*.example.com/api/*.json"></script>

One would intuitively expect that "to allow all subdomains of example.com", just as the readme states.

However, it appears to mean:

1. Allow requests from any resource originating from domains matching *.example.com
2. Whose path on slave.com matches /api/*json (slave.com, not example.com)

Which is great and precisely what I was hoping it would mean! But please correct me if I am mistaken regarding the above.

Which makes me wonder whether you have considered a master setting of something like '#' or even null to mean "go ahead with the request to the slave always, extract any Access-Control-Allow-Origin header value from the response, and use that for the origin match before outputting from the iframe?"

That is, emulate CORS with respect to origin matching.

It would avoid duplication for the server developer who wants to support both xDomain and CORS clients.

[turquoiseowl]

Then also with CORS we can determine dynamically whether or not to add the Access-Control-Allow-Origin header, based on arbitrary attributes of the request.

[jpillora]

I have thought of using CORS headers instead of the regex string as the whitelist. I just haven't had much time or much desire from users to add this feature. I'll modify this issue to be a feature request and we'll see if we get any +1s.

[turquoiseowl]

Right you are. xdomain is an inch away from being a polyfill for CORS (subset of) and new adoption of it extremely clean and inviting. Thanks.

[leandroferreira]

+1