You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This rule means that if an explicit public suffix can't be found for a domain in the PSL, the (actual, not effective) TLD is treated as a public suffix. This allows new TLDs (or custom internal TLDs) to be handled without requiring an explicit update to the PSL.
(It also means that the only time the PSL algorithm doesn't return a registrable domain is when the domain is itself a public suffix, which helps disambiguate that case.)
The last three results are turning '', when they should return example.example.
And the ExtractResult objects for all four results should have suffix='example', instead of domain='example'?
I'm worried about adopting this change. It would be breaking for anybody using this library to distinguish recognized suffixes from bogus ones or from internal hostnames like localhost.
Maybe a new property that honors the PSL formal algorithm? And/or a warning in the documentation?
The PSL formal algorithm includes the following step:
This rule means that if an explicit public suffix can't be found for a domain in the PSL, the (actual, not effective) TLD is treated as a public suffix. This allows new TLDs (or custom internal TLDs) to be handled without requiring an explicit update to the PSL.
(It also means that the only time the PSL algorithm doesn't return a registrable domain is when the domain is itself a public suffix, which helps disambiguate that case.)
The PSL project has tests for this in the standard test suite:
Here's the output for the test domains in
tldextract
5.1.2:The last three results are turning
''
, when they should returnexample.example
.The text was updated successfully, but these errors were encountered: