Following up on the 700+ unit test failures reported this morning, I've gone and cleaned up the iOS whitelist unit tests.
iOS had always had some crazy whitelist handling "features", but the full crazy was never completely documented. Our new whitelist roughly follows the spec at http://developer.chrome.com/apps/match_patterns.html, and drops some of the features previously supported. To be explicit (and generate discussion where needed,) these features have been changed / removed for iOS since Cordova 2.9: 1. There is no more magic TLD matching: You cannot specify "apache.*" and have it match "apache.us", "apache.ca", "apache.gl", "apache.aero", "apache.xxx", etc. This feature had some problems; it matches all 2-letter ccTLDs, but does not match useful domains like "apache.ac.uk", "apache.co.jp", etc. It had a hard-coded list of longer TLDs which needed to be updated in sync with the ICANN list. And it would always leave an app in a vulnerable position unless you were willing to purchase domain rights in every conceivable jurisdiction. 2. There is less magic protocol/scheme handling: "apache.org" should be equivalent to "*://apache.org", and matches http://apache.org and https://apache.org (by the spec). "*" matches *all* urls. If you need only "http[s]://*" and "ftp[s]://*", then just put those four patterns in your whitelist. 3. No crazy wildcards. Wildcards are permitted at the start of a host, at the end of a path, or as the scheme. Patterns like "ht*p://*.ap*he.o*g/" aren't recognized any more. 4. The whitelist mechanism tests against whole urls, rather than fragments. This means that you can test whether "http://www.apache.org/" matches your current whitelist, but if you try to test "apache.org", or even " http://www.apache.org", then those will fail. They aren't complete URLs, and so should never be generated as a link target or XHR source anyway. (Adding the trailing "/" is really a browser feature, just for typing URLs in the address bar anway. Apps will almost always be working with complete URLs.) Ian