On Wed, 17 Aug 2005, Jeff Pohlmeyer wrote:

> Yes, that does the trick, although I'm not familiar enough with the
> COOKIELIST stuff to really know what the "correct" behavior should be, other
> than the principle of least surprise.

That's kind of what I thought as well. In your use case, you'd _expect_ it to
write back all cookies it read from the file.

> FWIW, I am trying to update the Delphi/Pascal bindings, and I thought
> possibly to provide some sort of object-oriented methods to make the cookie
> handling a bit more transparent, but keeping the internal and external
> representation of cookielist, cookiefile, and cookiejar all synchronized is
> turning out to be a bit more work than I expected.
>
> For one thing, I had hoped that loading a CURLOPT_COOKIEFILE would
> automatically update the CURLINFO_COOKIELIST, but it looks like that doesn't
> happen until after curl_easy_perform. The simple solution on the user's side
> is to read the cookie file in manually line-by-line, and call
> CURLOPT_COOKIELIST for each line.

I no longer remember why we modified the COOKIEFILE stuff like this, but you
are indeed correct. When setting a file name with CURLOPT_COOKIEFILE the file
name is stored in a list and the files are read first when you invoke
curl_easy_perform(). That's also why this particular bug occurred, since no
cookies had been read from that file but you had added one with COOKIELIST and
when then saving the cookies with COOKIEJAR there was only one cookie to
write.

I'll atttempt to make a time travel back in the CVS repo to see if I can
figure out why we made COOKEFILE work like this and not simply load the file
at once. I might've been a way to avoid having to write the cookiejar if no
transfer was made, like in:

  COOKIEFILE = "file"
  COOKIEJAR = "file"

  *cleanup()

In the previous code (before my change yesterday), the file was not written
just because of this since it didn't actually load the cookies and thus there
were no cookies to save...

> That seems to work, it updates CURLINFO_COOKIELIST, but it brings up the
> question, is it safe to call curl_easy_getinfo before curl_easy_perform? The
> man page says that's a no-no, but it looks like there are already a couple
> of exceptions for CURLINFO_SSLENGINES and CURLINFO_PRIVATE.

I think this is also due to history. Back in the days when that phrase was
written in the curl_easy_getinfo man page we only had "variables" that
concerned transfers and they certainly didn't make any sense to read before a
transfer had been made (or attempted).

I'll update that description to better reflect today's status.

> Another thing I haven't figured out is how to delete a single cookie from
> the list. There was some mention in the preliminary discussions on
> http://curl.haxx.se/mail/lib-2004-12/0195.html :
>
> "To remove a cookie that libcurl already knows about, you simply set
> it with no contents, or you set it with an expired time."
>
> ... but currently that doesn't seem to have any immediate effect.

Right. This interface is somewhat weird for such a task. I suggest you instead
just set the cookie with an ancient expire time as that will at least prevent
the cookie from ever getting sent by libcurl.

Of course that is only true if you make sure you _read_ cookies from the
cookie file before expiring them with COOKIELIST. Hm, which might be just
another reason to make COOKIEFILE read the cookies at once and not delayed.

Another option is to support something "weird" in the format that signals
deletion, such as -1 in the expiry field or so.

> Of course, none of these issues is really essential to any ongoing project
> of mine, it's just an idea rolling around in my head on how to abstract the
> cookie handling in a way that looks more "delphi-ish"

I appreciate your thoughts and tests anyway. These are quirks we'd face sooner
or later anyway and having them somewhat ironed out before the first release
with COOKIELIST support feels better.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html