Re: Cookie handling

[sundialsvc4]

in reply to Cookie handling

I cordially suggest that you are dealing with an edge-case ... and the moment that you said that different browsers do it differently, the pragmatic verdict was coffin-nailed down.   You simply need to be sure that the cookie names are unique.   Instead of viewing the present implementation (which you observe is repeated in several places) as being either a bug or a limitation ... treat it as It Works That Way.™   You’ve got a program to write, and these aren’t the ’droids you’re looking for ...

As we all know, there will be dozens of This Sucks! and This Is Wrong! and This Is Stupid! ... every release of Internet Explorer provides us with a couple more outhouses full of that.   So you’ll never run out of nodding heads here.   And yet, somehow, despite all of this, we have programs to write.

[McA]

Hi,

thank you for your comment. Generally I agree with you. I wrote that I lived happy with the well known and used implementations until I struggled with such an edge case. You can be sure it costed some time to debug the problem. I'm not actively using such edge cases. Besides of getting hints for other good modules I wanted to raise the awareness that there are edge cases most people (including me until now) don't think about.

The current implementation doesn't use the domain attribute of the cookie to achieve that the cookie is only sent to the origin server as stated in the RFC. So our server is sending only one type and name of cookie. Now we found some requests sending two cookies with the same name. I was wondering and had the luck to get in touch with a person who has a client causing this problem. We investigated the cookie store and found out that there were two cookies with different domain attributes, one with '.www.ourdomain.de' and one with 'www.ourdomain.de'. Both were sent along with requests to www.ourdomain.de. Don't ask me how it came to the cookie with the domain '.www.domain.de'. Probably a buggy browser, a proxy, manual intervention. I don't know. Now to the worse. Along with the HTTP reply the intended cookie was sent, and it was updated on the client side. But the one we don't like is always sent as first cookie and therefore catched in the method fetch of CGI::Cookie. In this special case we could look at the cookie store to find out that the wrong domain attribute '.www.ourdomain.de' was the reason. On the server side alone you're not able to see which instance of the triple 'cookie-name/domain/path' is responsible for sending a name=value pair you see in the headers. So you're not even able to delete such an evil cookie by sending a "delete" cookie addressing the wrong triple.

So, what can someone do now?

By the way: This kind of duplicate cookie can be tested with the same negative impact on several big sites.

One idea would be to explicitly delete all cookie triples (name/domain/path) you don't want and only set the one you like. In this case you must assure the right sequence of cookie headers. You don't have influence on that when you use the hash-like api of cookie setting. (Oh, we have a reference to the hash key order problem of some modules)

Anyway: Hints, tips, best practices appreciated. Even if I don't get them I hope someone will find that issue interesting especially in this corner case.

One additional comment: When you once decide to change a persistent host cookie (no domain attribute) to a domain cookie because e.g. you like to send the cookie also to several cdn subdomains you can't simply change the domain attribute as this would lead exactly to the problem described. Either you use a new cookie name or you have to explicitly delete the "old" host cookie.

Best regards
McA