-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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 returns true for "za" domains not in the list #22959
Comments
CC @nigeltao |
The current behavior of @eminano is correct, the suffix doesn't exists in the list.
However, the recommended PSL algorithm also encourages to use Until this point, the behavior is technically correct, according to the current PSL definition. Which is why it is not necessarily a bug. From here my assumption is that at this point What I agree with is that this behavior can be surprisingly, and it's a subtle side effect. In my Go implementation of the PSL I leave it possible to disable the default package main
import (
"fmt"
"github.com/weppos/publicsuffix-go/publicsuffix"
)
func main() {
r := publicsuffix.DefaultList.Find("gli.za", &publicsuffix.FindOptions{DefaultRule: nil})
fmt.Println(r)
} This code returns a
which makes it easier to understand the rule doesn't match. At that point, the consumer has full power to decide what to do. Likewise, by default my library behaves exactly like the package main
import (
"fmt"
wpsl "github.com/weppos/publicsuffix-go/net/publicsuffix"
xpsl "golang.org/x/net/publicsuffix"
)
func main() {
ws, we := wpsl.EffectiveTLDPlusOne("foo.gli.za")
xs, xe := xpsl.EffectiveTLDPlusOne("foo.gli.za")
fmt.Println(ws, we)
fmt.Println(xs, xe)
}
The main difference is that @eminano I would be interested to learn a little bit more about what you are using the list for, and how you came to this issue. Specifically, what you use the ICANN for. I opened a specific issue to clarify the intent also in the list itself: publicsuffix/list#570 Your feedback would help to have a better understanding and perhaps provide you an alternative. |
@weppos Thanks for your reply! You are right, there's nothing specified about the ICANN flag, so I will restrict my comparison/mirroring to the public suffix returned. |
@eminano out of curiosity, any reason to not use |
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?
I tested domains such as "gli.za" not present in the public suffix list.
https://play.golang.org/p/DaJICtp00J
What did you expect to see?
I expected to have icann flag set to false, since the domain is not in the public suffix list.
// za : http://www.zadna.org.za/content/page/domain-information
ac.za
agric.za
alt.za
co.za
edu.za
gov.za
grondar.za
law.za
mil.za
net.za
ngo.za
nis.za
nom.za
org.za
school.za
tm.za
web.za
What did you see instead?
icann flag set to true
I added debugging lines locally to check why the flag was being set and to see if there was a rule found. I saw that the code was going through the following steps (https://github.com/golang/net/blob/master/publicsuffix/list.go#L47):
Is this the expected behaviour? It seems like a corner case, given "za" is one of the rare domains in the list that does not include the base level ("za"), but only 2 level domains.
The text was updated successfully, but these errors were encountered: