curl-library
Re: 7.18.2: Possible bug in converting a cookie's expires attribute to unix timestamp ?
Date: Fri, 5 Sep 2008 09:33:32 +0200 (CEST)
On Wed, 3 Sep 2008, Stefan Krause wrote:
> libCurl 7.18.2 was used. I set a cookie with an expiration date <= Thu,
> 01-Jan-1970 00:59:59 GMT. That is converted to -1 (should be 3599, or ?).
It is only 3599 if you're in the GMT time zone.
I assume you're in CEST land (time zone wise)? Then it isn't. We could of
course argue how we can fix the -1 from not happening when you're close to the
border of what mktime() can fix - the reason this fails is that the code adds
the specific time using your local timezone and then it compensates for the
time zone in the data. Thus, it tries to get 01-Jan-1970 00:59:59 CEST first,
which occurred _before_ time_t 0.
I don't consider this a particularly important detail so I'll ignore this for
now.
> libCurl internally handles that cookie as session cookies, because the
> expires value <= 0 and sends it to the server next time (despite it is
> expired !).
That's indeed a true bug. I figure we should simply consider -1 dates as
invalid (expired) unconditionally so only (co->expires== 0 || co->expires>
now) sends the cookie. Right?
> Expiration date Thu, 01-Jan-1970 01:00:00 GMT is converted to 1, but should
> be 3600 !?.
This is the same reason as above. I added both these dates to test 517 and ran
it, and both dates turned out fine since the test sets TZ=GMT...
Thanks for your detailed report and research.
-- / daniel.haxx.seReceived on 2008-09-05