+1 for consistency
On Fri, Aug 30, 2013 at 11:00 PM, Ian Clelland <iclell...@chromium.org>wrote: > 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 >
