Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Cookie handling

by McA (Curate)
on Dec 04, 2012 at 16:18 UTC ( #1007112=perlquestion: print w/ replies, xml ) Need Help??
McA has asked for the wisdom of the Perl Monks concerning the following question:

Hi all,

at the moment I'm working on code which uses CGI::Cookie for fetching and building cookies. So far, so good. I've to admit that I was never interested in the details of cookie headers until today (I've read the RFC now). But now to the problem:

It seems to be absolutly valid that you produce more than one cookie with the same name. Whether this is meaningful or not is something different. But it is possible. It's also possible, that you get more than one cookie with the same name. Looking at the last RFC 6265 shows that the key for a unique cookie is the triple name/domain/path. E.g if you set a cookie 'test' for 'domain.de' and a cookie 'test' for 'host.domain.de' and you're sending a request to host.domain.de you will see two cookies with name 'test' in the Cookie-Header.

CGI::Cookie can't handle this as it uses the cookie name as a key to a hash holding all cookies. So, as soon as you have two cookies with the same name you fetch only the first one. I found this snippet in CGI::Cookie:

# A bug in Netscape can cause several cookies with same name to # appear. The FIRST one in HTTP_COOKIE is the most recent version. $results{$key} ||= $self->new(-name=>$key,-value=>\@values);

Is there any good cookie handling module out there which can handle the case of two or more cookies of same name?

By the way: Plack::Request does also have this "shortcomming". The good thing: tDocumentation states this clearly. It's IMHO a pitty as Plack::Request is relativly new and has Hash::MultiValue introduced in some cases.

I did also some testing of the way browsers handle different cookies (domain, path) with same cookie name. That's really interesting as there is a ugly difference between Firefox/Safari/Chrome and IE/Opera where I do believe at the moment that IE/Opera are doing it right.

Hints appreciated.

Best regards
McA

Comment on Cookie handling
Download Code
Re: Cookie handling
by sundialsvc4 (Monsignor) on Dec 04, 2012 at 16:47 UTC

    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.

      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

Re: Cookie handling
by afoken (Parson) on Dec 05, 2012 at 19:49 UTC
    # A bug in Netscape can cause several cookies with same name to # appear. The FIRST one in HTTP_COOKIE is the most recent version.

    I know this comment from ancient times of CGI.pm. I think it is for Netscape Navigator 4 or even an older version. It is present in the oldest version available on CPAN, v2.45 released 1998-Nov-25. At that time, Netscape Navigator 4.08 was the latest version, and many users still used NN 4.0 or NN 3.x.

    NN has not seen a new release since 2008 and is effectively dead. I consider the commented hack legacy code, almost cargo cult. It does not hurt to have it there, but I doubt it has any effect with any browser released in the last years.

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      Hi,

      the funny thing is, that now (I don't know since when) it's not a bug to send more than one cookie with the same name.

      Best regards
      McA

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1007112]
Approved by cjb
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (6)
As of 2014-09-03 03:08 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite cookbook is:










    Results (35 votes), past polls