Skip Menu |
 

This queue is for tickets about the libwww-perl CPAN distribution.

Report information
The Basics
Id: 50147
Status: resolved
Priority: 0/
Queue: libwww-perl

People
Owner: Nobody in particular
Requestors: rvandam00 [...] gmail.com
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: 5.827
Fixed in: (no value)



Subject: HTTP::Cookies handles dates after epoch poorly (due to str2time)
Download (untitled) / with headers
text/plain 1.3k
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.
Download (untitled) / with headers
text/plain 171b
Fixed by http://github.com/gisle/libwww- perl/commit/1b9cc45a73c8e34bf43d2d6c48232f125b12089e I did not see any noise from Time::Local to supress with the perl I'm using.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.