Closed Bug 725530 Opened 10 years ago Closed 10 years ago
How does the public suffix list test data determine local is not a true TLD
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.11 (KHTML, like Gecko) Chrome/17.0.963.44 Safari/535.11 Steps to reproduce: I'm running the official test suite from Public Suffix website: http://publicsuffix.org/list/test.txt Actual results: All rules pass on my implementation but these 3: # Listed, but non-Internet, TLD. checkPublicSuffix('example.local', NULL); checkPublicSuffix('b.example.local', NULL); checkPublicSuffix('a.b.example.local', NULL); The issue is according to the effective TLD names local shows up as a valid TLD. See http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat#1842 Expected results: Looking at the comment in the test file '# Listed, but non-Internet, TLD' It seems to indicate that there is a way to know if its a non-Internet TLD? By looking at the effective TLD list how do we know which ones are 'non-internet'?
Component: General → Networking
QA Contact: general → networking
There is no programmatic way to know. We plan to sort the list into (terminology for the two groups is subject to change): - ICANN registrar-controlled Public Suffixes (e.g. co.uk) - Privately-controlled Public Suffixes (e.g. appspot.com) However, .local is an odd case. I'm not sure what we'll do with that... Gerv
Since there is no programmatic way to know, I would recommend taking .local out of the test file for now, until you build a new rule for intranet based TLDs. I like the idea of distinguishing out official ICANN registrar suffixes and pseudo-private suffixes.
Sending list/test.txt Transmitting file data . Committed revision 101854. Gerv
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.