Doesn't handle cookies where the Domain starts with a dot. about anglesharp.io HOT 7 OPEN

OK we need a spec to back this up. Can you point to a spec where this is written?

excluding a leading "www." or "."

I can already guarantee you that "www." should not be excluded. It's a subdomain like any other. Regarding the "." I'd like to see a spec that defines such edge cases and how they should be handled. I think this might be a case for some normalization, but I need some spec confirmation.

from anglesharp.io.

from anglesharp.io.

Perhaps the change needs to be in the matching algorithm and instead of
looking for an absolute match, checking to see if the cookie domain forms
part of the URL domain?

I'd not change the matching algorithm - I'd rather normalize what we see in the domain field. From the RFC it seems that the leading dot is the change necessary, otherwise all algorithms can continue to work as-is. So if we normalize this input from the domain field (only chance a leading dot appears) then we should be fine.

from anglesharp.io.

from anglesharp.io.

Surely you have to change the matching algorithm though. At present the match must be exact between the URL domain and the cookie domain. So whether or not a leading dot is included, the cookie is excluded.

No - as I wrote; if we normalize the input then the matching algorithm does not need to be changed. There will never be a dot in front of a domain.

For me a change from cookie.Domain.Is(domain) to domain.EndsWith(cookie.Domain, StringComparison.OrdinalIgnoreCase) in
both FindCookie and FindCookies makes the behaviour as expected.

This will not work in general. Yes, of course it works in your case - but then you could also just "return true". Because if domain is "www.foobar.com" it would also match a cookie.Domain of "bar.com", but it should only match "foobar.com".

from anglesharp.io.

It works if you include the "." in the cookie retained.
That requires further change

Need to store a cookie ".mywebsite.com" such that it matches requests to www.mywebsite.com AND www.foo.mywebsite.com etc.
But as you point out, it should NOT match www.thisismywebsite.com.

There's no way around that without altering the matching algorithm.

from anglesharp.io.

There's no way around that without altering the matching algorithm.

I agree that the matching algorithm in general needs to be changed, but not due to the dot. The dot has to be taken care of in an input normalization. We'll remove the leading dot and handle all those cases in the matching algorithm.

If you'd retain the dot you'd always need to take care of it in the matching algorithm, which does not make much sense. You can already remove it beforehand and drop that case immediately. Matching will be done more often than setting / writing - so normalizing the input makes sense also from a performance POV. It's just unnecessary work to retain the dot.

As the spec said - "foo.com" and ".foo.com" should behave the same. So let's normalize ".foo.com" to be "foo.com".

from anglesharp.io.