| Subject: | HTTP::Cookies handles dates after epoch poorly (due to str2time) |
If given a cookie date after the epoch (such as "Tue 19 Oct 2077
11:41:14 AM MST" which i just saw in the wild), HTTP::Cookies spews
something like this:
Day too big - 39373 > 24855
Sec too small - 39373 < 74752
Sec too big - 39373 > 11647
These warnings actually come all the way from Time::Local being used by
HTTP::Date::str2time(). I recommend these warnings get captured and
perhaps a more useful warning given (such as "Cookies expiring after the
local epoch of blah blah 2038 cannot be handled").
I suppose it probably makes the most sense to alter the warning in
HTTP::Date first since direct consumers of str2time() should be aware of
the epoch limitations and may need to roll their own str2time if they
use such dates. However, HTTP::Cookies is most often used in cases
where the date input cannot be controlled (and lots of people set
cookies as essentially forever by just setting them far in the future)
so it seems necessary to also handle this case directly in HTTP::Cookies.
Besides the warnings, the corresponding cookie is also not kept due to
no valid date being returned by str2time/Time::Local. If the error is
properly cascaded, one useful work-around could be to set distant
expirations as being just before the epoch. Probably not compliant with
an RFC somewhere but seems better than throwing it away entirely.