> I disagree. Well, sure, one way to add this would be to add another option
> that would be used by a very very tiny fraction of our users. But we
could
> just as well simply add new timecondition types that causes a failure if
they
> evaluate true. It would make the old programs work as before, while new
ones
> could use the new conditions.
>
> However, that would not address my concerns about returning error when
there
> really isn't an error.
>
> In fact, this error vs info returning is a subject for some more thinking.
>
> This particular case could in fact also be solved by adding another
variable
> readable with curl_easy_getinfo(). Perhaps that is the cleanest solution.

Yeah that might work. something along the lines of:
curl_easy_getinfo(curl, CURL_INFO_TIMECONDITION, &bool);
if (bool == 1)
/* The time condition was met and therefore the file was downloaded */
else
/* The time condition was not met and therefore the cached version should be
used */

Again, if you think that's a good solution I'd be glad to work on it.

Regardless though I've attached a minor patch to update the docs. The docs
says that timeconditions only apply to HTTP, that's not true. Libcurl
attempts to get the file's modification time for FTP transfers, and it will
do just like it does with the HTTP Last-Modified header, it will check the
conditions itself. So I've moved the CURLOPT_TIMECONDITION/VALUE to not be
listed under the HTTP section and to also note that it may work for FTP as
well if the modification time can be retrieved.

Dominick Meglio