I wrote:
Johannes wrote:
To me it seems reasonable what other browsers do here, even if the standard states it differently.
I've discovered that the http-state working group is actively trying to come up with something that reflects what is good and sensible for clients and servers to do. So I'm reading through their mailing list archives and all that...
Their algorithm is that you pretend that you don't see any leading dots, and the domain-matching is done such that the .domain cookie is sent with queries to both sub.domain and domain. So that's the currently "normal" thing... Interestingly (alarmingly), only RFC cookies specify path/domain when sent from user agent to server, and, as I've said, pretty much everything ignores RFCness, so for instance if there could be a NAME=VAL1 sub.domain cookie and a NAME=VAL2 domain cookie and you have one of them, it's the task of people writing the server code to make sure they can tell what it belongs to. And if a user agent accidentally accepts/sends a cookie for a tld or something, no one will realize this. Speaking of alarming, it seems that it's normal to accept cookies for /path1 sent from /path2. That's irritating in part because I just disallowed that the other day.