-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
x/net/publicsuffix: ICANN flag returned not aligned with public suffix location in the list #22985
Comments
I think this behavior is expected at least from the perspective of the official PSL repo. Build 7 which has change:
results in failure. Build 8 which has change:
results in success. Build 9 which has change:
results in success. Note that there were no other changes between these builds. Compare the cases here: https://github.com/meirf/list/blob/master/tests/tests.txt#L40-L49, note the pattern of This answer is purely based on the official repo behavior. Perhaps @vdobler, @weppos can give some additional insights/correct my results. |
Thanks for bringing it to the attention. At first glance, I'd say the match should be against However, it's interesting we don't have a proper test case. I also checked it against 2 libraries I maintain. The Go lib matches against the I'll bring this issue to the PSL list to make sure the interpretation is correct and make sure we address it. |
Fro my reading "transurl.be" would be matched only by the rule "be" and not by "*.transurl.be" as the nothing in "transurl.be" matches the *. This icann should be true. So it is a real bug. |
I believe this is the source of the confusion. From the formal algorithm:
Emphasis is mine. It means, given two rules:
If you try to match
In other words, in case the rule contains
should all match I think this is one of those cases where it's worth to invest some effort on the PSL side to reach a consensus and standardize all the implementations. I am definitely bringing it up for discussion (I'll add a reference to the ticker and/or thread here). |
@weppos I doubt that this reading is correct. *.example.be has three labels. From right to left these are "be", "example" and "*". example.be has two labels: "be" and "example" So the domain example.be can never match the rule *.example.be because the domain has fewer labels than the rule. The * is a label; it is not "a label or no label". |
While trying to fix this bug I found one more thing I think is underspecified: What is the icann flag for "bd"? There is just one rule for bd:
(the rule is in the ICANN section). With the official PSL algorithm the domain "be" would not match the rule ".bd" (Note: The strange rule "*.bd" seems to be a "fix" for some test case break.
and
Where the later with the explicit rule for "bd" seems saner. |
It looks like this is an old issue. I've resurrected the discussion. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.9.2
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?goos: darwin
goarch: amd64
What did you do?
Call PublicSuffix with input domain "transurl.be"
https://play.golang.org/p/SLdVLEzpk4
What did you expect to see?
ICANN flag set to true
List contains "be" within the ICANN delimiters:
// be : https://en.wikipedia.org/wiki/.be
// Confirmed by registry tech@dns.be 2008-06-08
be
ac.be
and "*.transurl.be" outside.
// TransIP : htts://www.transip.nl
// Submitted by Rory Breuk rbreuk@transip.nl
*.transurl.be
*.transurl.eu
*.transurl.nl
What did you see instead?
ICANN flag set to false
I am not sure if this behaviour is expected. Should transurl.be match *.transurl.be, given it doesn't have a 3rd level domain?
Also, since the public suffix domain returned is "be" , I would expect for that rule to be the one being matched, and therefore having ICANN set to true.
There are more occurrences of this scenario, such as "0emm.com".
The text was updated successfully, but these errors were encountered: