foo and *.foo rules (follow up)

[Simone Carletti]

Hello,

I'm resurrecting the discussion Add "foo" rule for all occurrences of "*.foo" in PSL as coincidentally I've just happened to be pinged a few days ago in an issue originated in the Go PSL implementation

https://github.com/golang/go/issues/22985 that in fact is caused by exactly the same issue (unless I'm mistaken).

It looks like the chance this issue occurs is increasing now that we registered an increase in the amount of entries in the PRIVATE section.

#1139842 is a very long thread. Thankfully, Gerv put together a great wiki page that summarizes it:

https://wiki.mozilla.org/Public_Suffix_List/platform.sh_Problem

As I mentioned in the Go ticket, I was tricked by this issue too. Apparently, one of my lib implementations expose one behavior, and the other a completely opposite behavior.

In the thread there is a reference to an hypothetical bug in Chrome. I would be interested to know what path was taken there.

There is also a reference to a Mozilla ticket that is still open.

> So, if the PSL contains two rules, "*.foo" and "foo", this code will consider them the same.

> That's bad - they are not the same. We want to encode such rules in the PSL (see bug 1139842) but we can't, because this code can't copy.

I must admit so far I had the implicit impression that we could/should not have these two rules together because redundant.

I'm very well aware that they are not the same rule, but implicitly I've interpreted them to be a single one, perhaps mistakenly. And it seems I may not be the only one.

https://github.com/publicsuffix/list/pull/663 is also a very recent PR where the submitter proposed both the wildcard and non wildcard version, hence before we move forward I think it may be helpful to clarify the interpretation here.

-- Simone

[Ryan Sleevi]

On Mon, May 21, 2018 at 8:13 AM, Simone Carletti <wep...@weppos.net> wrote:

Hello,

I'm resurrecting the discussion Add "foo" rule for all occurrences of "*.foo" in PSL as coincidentally I've just happened to be pinged a few days ago in an issue originated in the Go PSL implementation

https://github.com/golang/go/issues/22985 that in fact is caused by exactly the same issue (unless I'm mistaken).

It looks like the chance this issue occurs is increasing now that we registered an increase in the amount of entries in the PRIVATE section.

#1139842 is a very long thread. Thankfully, Gerv put together a great wiki page that summarizes it:

https://wiki.mozilla.org/Public_Suffix_List/platform.sh_Problem

As I mentioned in the Go ticket, I was tricked by this issue too. Apparently, one of my lib implementations expose one behavior, and the other a completely opposite behavior.

In the thread there is a reference to an hypothetical bug in Chrome. I would be interested to know what path was taken there.

There is also a reference to a Mozilla ticket that is still open.

I'm not sure the hypothetical bug. It's still a bug, and it's still unresolved - https://bugs.chromium.org/p/chromium/issues/detail?id=459802

 

> So, if the PSL contains two rules, "*.foo" and "foo", this code will consider them the same.

> That's bad - they are not the same. We want to encode such rules in the PSL (see bug 1139842) but we can't, because this code can't copy.

I must admit so far I had the implicit impression that we could/should not have these two rules together because redundant.

I'm very well aware that they are not the same rule, but implicitly I've interpreted them to be a single one, perhaps mistakenly. And it seems I may not be the only one.

https://github.com/publicsuffix/list/pull/663 is also a very recent PR where the submitter proposed both the wildcard and non wildcard version, hence before we move forward I think it may be helpful to clarify the interpretation here.

Agreed. It would be useful to hear from other implementors as well.