Hi There,

It might be valuable to rename the config-mac.h file to config-macos9.h That
way people will not include it when building for OS X.

This could have saved me a lot of cycles.

Ramesh

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Friday, September 05, 2008 12:34 AM
To: libcurl development
Subject: Re: 7.18.2: Possible bug in converting a cookie's expires attribute
to unix timestamp ?

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.se