This particular piece of code in HTTP::Cookies bothers me in 2 ways.
------------------------------------------------------------
276 if ($lc eq "expires") {
277 my $etime = str2time($v);
278 if ($etime) {
279 push(@cur, "Max-Age" => str2time($v) - $now);
280 $expires++;
281 }
-----------------------------------------------------------
firstly, line 279 could be optimized as follows to avoid another
str2time() call:
279 push(@cur, "Max-Age" => $etime - $now);
secondly, the conditional on line 278 has an undocumented pitfall.
str2time relies on Time::Local::timegm() which returns -1 if the integer
limit is hit for unix timestamps. str2time will return undef when a given
expire time is after Jan 1st, 00:00 2038.
This results in incorrect saving behavior for cookies that have expire
times any time after 2038. Valid cookies are incorrectly saved with the
"discard" attribute and no expire attribute. This should be documented in
HTTP::Cookies as a warning to developers; or in my case, I have
HTTP::Cookies patched to return a date of [Jan 1, 2038 00:00] for any
dates after the integer limit. This is an obvious kludge, anyone have any
better suggestions?
An example of this issue in action is cookies from http://www.etoys.com
which carry an expire date of Jan 1, 2038 00:01.
thanks,
Frey Kuo
