la mouton <[EMAIL PROTECTED]> writes:
> 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);
Sure. I don't know what I was smoking when I wrote that code :-)
> 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.
We could hope that this limit simply goes away as we approach this
year :-)
> 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?
I think the best cure is to make HTTP::Date::str2time() return INT_MAX
when the date overflows.
--
Gisle Aas
