Bug #34216 for CGI-Session: Safari does not handles relative expiration value for cookie

Wed Mar 19 02:09:45 2008 angelospam [...] proofpoint.com - Ticket created

Subject:

Safari does not handles relative expiration value for cookie

I'm settings an expiration time with a relative time (like "+60") and it works fine in IE and Firefox, but Safari does not accept this cookie. I found out that Safari only accept a absolute time in the format of "Sat, 01-Jan-2000 01:01:01 GMT". Since this date format is accepted by all other browsers, i would suggest the sub "cookie" returns this type of date..

Wed Mar 19 09:49:58 2008 MARKSTOS [...] cpan.org - Taken

Wed Mar 19 09:52:54 2008 MARKSTOS [...] cpan.org - Correspondence added

On Wed Mar 19 02:09:45 2008, astar wrote: Show quoted text

> I'm settings an expiration time with a relative time (like "+60") and it > works fine in IE and Firefox, but Safari does not accept this cookie. I > found out that Safari only accept a absolute time in the format of "Sat, > 01-Jan-2000 01:01:01 GMT". Since this date format is accepted by all > other browsers, i would suggest the sub "cookie" returns this type of

date.. I suggest you debug this further. "+60" gets translated into a HTTP standard date format indicating an expiration time that is 60 seconds from now. Since you didn't specify the units, I'm not sure if that's what you expected. The docs could be clearer that not specifying a unit defaults to seconds, if you'd like to patch them. To better understand the problem, I suggest that you submit a failing Test::More style test case that illustrates that the problem. This will confirm exactly what the issue is, and help us to address the bug if one is found to exist. Mark

Wed Mar 19 09:52:55 2008 The RT System itself - Status changed from 'new' to 'open'

Wed Mar 19 09:52:56 2008 MARKSTOS [...] cpan.org - Status changed from 'open' to 'stalled'

Wed Mar 19 12:12:23 2008 angelospam [...] proofpoint.com - Correspondence added

From:

angelospam [...] proofpoint.com

On Wed Mar 19 09:52:54 2008, MARKSTOS wrote: Show quoted text

> On Wed Mar 19 02:09:45 2008, astar wrote:

> > I'm settings an expiration time with a relative time (like "+60") and it > > works fine in IE and Firefox, but Safari does not accept this cookie. I > > found out that Safari only accept a absolute time in the format of "Sat, > > 01-Jan-2000 01:01:01 GMT". Since this date format is accepted by all > > other browsers, i would suggest the sub "cookie" returns this type of

> date.. > > I suggest you debug this further. "+60" gets translated into a HTTP > standard date format indicating an expiration time that is 60 seconds > from now. Since you didn't specify the units, I'm not sure if that's > what you expected. The docs could be clearer that not specifying a unit > defaults to seconds, if you'd like to patch them. > > To better understand the problem, I suggest that you submit a failing > Test::More style test case that illustrates that the problem. This will > confirm exactly what the issue is, and help us to address the bug if one > is found to exist. > > Mark > >

basically I'm settings the expiration time in seconds: $session->expire('3600s'); the cookie will look like: somekey=somevalue; path=/; expires=+3600s This is accepted by IE/Firefox, but Safari won't accept this type of expiration and will ignore the cookie. Safari will only accept a cookie with an expiration like this: somekey=somevalue; path=/; expires=Sat, 01-Jan-2000 01:01:01 GMT

Wed Mar 19 12:12:24 2008 The RT System itself - Status changed from 'stalled' to 'open'

Wed Mar 19 15:45:53 2008 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #34216] Safari does not handles relative expiration value for cookie
Date:	Wed, 19 Mar 2008 15:29:05 -0400
To:	bug-CGI-Session [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

Show quoted text

> basically I'm settings the expiration time in seconds: > > $session->expire('3600s'); > > the cookie will look like: > > somekey=somevalue; path=/; expires=+3600s > > This is accepted by IE/Firefox, but Safari won't accept this type of > expiration and will ignore the cookie. Safari will only accept a cookie > with an expiration like this: > > somekey=somevalue; path=/; expires=Sat, 01-Jan-2000 01:01:01 GMT

Here's what I found out with a few minutes of research: This is the RFC governing cookies and their timestamp formats: http://www.w3.org/Protocols/rfc2109/rfc2109 - It defines "Max-Age" which takes a number of seconds, like "3600". There would be trailing "s" in that case. This the recommended way to set cookies. - For historical reasons, it also defines "Expires", which expects a data in the format above. - CGI::Session uses CGI.pm to actually set our cookies. CGI.pm supports both Expires and Max-Age, but only added Max-Age after 2.83, and still doesn't not document "Max-Age", even though it is the method recommended by the RFC. It sounds like the CGI.pm docs should be patched, and perhaps our own code should be patched so that we generate RFC-compliant cookies that set "Max-Age" instead of expires. Could you help put these patches together since this bug directly affects you? Mark

Fri Mar 21 14:54:48 2008 michael [...] summersault.com - Ticket #34329: Ticket created

Subject:	[patch] use max-age instead of expires
Date:	Fri, 21 Mar 2008 14:54:21 -0400
To:	bug-CGI-Session [...] rt.cpan.org
From:	Michael Hampton <michael [...] summersault.com>

Attached is a patch to generate RFC 2109 compliant cookies that set Max-Age instead of Expires. The patch is for version 4.20. Reference: http://www.w3.org/Protocols/rfc2109/rfc2109 Michael

Message body is not shown because sender requested not to inline it.

Fri Mar 21 15:07:44 2008 MARKSTOS [...] cpan.org - Ticket #34329: Merged into ticket #34216

Fri Mar 21 15:07:44 2008 MARKSTOS [...] cpan.org - Merged into ticket #34216

Fri Mar 21 21:39:54 2008 MARKSTOS [...] cpan.org - Correspondence added

To the original reporter: After reviewing this in detail, I believe this is not a bug in CGI::Session at all. While the RFC comments on "expire" vs "Max-Age" are interesting, I don't believe they are related here. To produce the result you saw like "expires=+60s", CGI::Session would have had to correctly pass the value "60" to the query object, which is then responsible for building the cookie text. The following demonstrates that both the current CGI.pm and CGI::Simple return the right result. Therefore, I conclude that you were using an older CGI.pm or CGI::Simple or some other buggy query object. Which query object were you using, and what version was it? ### use CGI::Cookie; my $cookie = CGI::Cookie->new( '-name' => 'n', '-value' => 'v', '-expires' => '+2s', ); print "$cookie\n"; use CGI::Simple::Cookie; my $cookie2 = CGI::Simple::Cookie->new( '-name' => 'n', '-value' => 'v', '-expires' => '+2s', ); print "$cookie2\n"; # Result: # n=v; path=/; expires=Sat, 22-Mar-2008 01:26:57 GMT # n=v; path=/; expires=Sat, 22-Mar-2008 01:26:57 GMT

Sat Mar 22 00:24:52 2008 angelospam [...] proofpoint.com - Correspondence added

From:

angelospam [...] proofpoint.com

On Fri Mar 21 21:39:54 2008, MARKSTOS wrote: Show quoted text

> To the original reporter: > > After reviewing this in detail, I believe this is not a bug in > CGI::Session at all. While the RFC comments on "expire" vs "Max-Age" are > interesting, I don't believe they are related here. > > To produce the result you saw like "expires=+60s", CGI::Session would > have had to correctly pass the value "60" to the query object, which is > then responsible for building the cookie text. The following > demonstrates that both the current CGI.pm and CGI::Simple return the > right result. Therefore, I conclude that you were using an older CGI.pm > or CGI::Simple or some other buggy query object. Which query object were > you using, and what version was it? > > ### > > use CGI::Cookie; > my $cookie = CGI::Cookie->new( > '-name' => 'n', > '-value' => 'v', > '-expires' => '+2s', > ); > print "$cookie\n"; > > use CGI::Simple::Cookie; > my $cookie2 = CGI::Simple::Cookie->new( > '-name' => 'n', > '-value' => 'v', > '-expires' => '+2s', > ); > print "$cookie2\n"; > > # Result: > # n=v; path=/; expires=Sat, 22-Mar-2008 01:26:57 GMT > # n=v; path=/; expires=Sat, 22-Mar-2008 01:26:57 GMT

okay, got to the bottom of this, i'm using CGI::Util version 1.5 in the code to calculate time: } elsif ($time=~/^([+-]?(?:\d+|\d*\.\d*))([mhdMy])/) { as you can see it does not handle seconds! (s) Looking at the latest CGI::Util 1.5_01 } elsif ($time=~/^([+-]?(?:\d+|\d*\.\d*))([smhdMy])/) { it's now supporting seconds! Thanks for your help, greatly appreciated!

Mon Mar 24 09:57:41 2008 MARKSTOS [...] cpan.org - Correspondence added

Subject:	whether or not to require a newer CGI.pm
From:	MARKSTOS [...] cpan.org

This looks like it was fixed in CGI.pm 3.26: Version 3.26 ... 6. Fixed bug in seconds calculation in CGI::Util::expire_calc. We don't currently require CGI.pm (since other query objects can be used), but maybe we should require at least this version to avoid the error. Mark

Sun Apr 06 20:23:31 2008 RSAVAGE [...] cpan.org - Correspondence added

On Mon Mar 24 09:57:41 2008, MARKSTOS wrote: Show quoted text

> We don't currently require CGI.pm (since other query objects can be > used), but maybe we should require at least this version to avoid the > error.

Here's a suggestion: I could patch Makefile.PL and Build.PL to require CGI V 3.26, and patch to docs to emphasize that this requirement is for a specific purpose (a pre-emptive defense against Safari), and that other modules, e.g. CGI::Simple can still be used. Would that be OK?

Mon Apr 07 09:40:15 2008 mark [...] summersault.com - Correspondence added

Subject:	Re: [rt.cpan.org #34216] Safari does not handles relative expiration value for cookie
Date:	Mon, 07 Apr 2008 09:39:41 -0400
To:	bug-CGI-Session [...] rt.cpan.org
From:	Mark Stosberg <mark [...] summersault.com>

RSAVAGE via RT wrote: Show quoted text

> Queue: CGI-Session > Ticket <URL: http://rt.cpan.org/Ticket/Display.html?id=34216 > > > On Mon Mar 24 09:57:41 2008, MARKSTOS wrote: >

>> We don't currently require CGI.pm (since other query objects can be >> used), but maybe we should require at least this version to avoid the >> error.

> > Here's a suggestion: I could patch Makefile.PL and Build.PL to require > CGI V 3.26, and patch to docs to emphasize that this requirement is for > a specific purpose (a pre-emptive defense against Safari), and that > other modules, e.g. CGI::Simple can still be used. Would that be OK?

That would be fine. I might describe the reason as: "To insure we generate cookie expiration times which follow the HTTP RFC, which Safari in particular is strict about." In general, thanks for stepping up with the maintenance, Ron. Just let me know when you'd like the next release to be pushed. Since CGI.pm is in the core, people can't complain too much about having a copy sitting around even if they don't use, since there's most likely already a copy of it in their distribution anyway. Mark -- . . . . . . . . . . . . . . . . . . . . . . . . . . . Mark Stosberg Principal Developer mark@summersault.com Summersault, LLC 765-939-9301 ext 202 database driven websites . . . . . http://www.summersault.com/ . . . . . . . .

Fri Oct 31 21:25:10 2008 MARKSTOS [...] cpan.org - Correspondence added

I'm going to release the fix Ron Savage recommended for this today.

Fri Oct 31 21:25:12 2008 MARKSTOS [...] cpan.org - Status changed from 'open' to 'resolved'