On Thu, 7 Jul 2005, Arvind Sachdeva wrote:

> I am using curl in my app. I am trying to add elaborate cookie support to
> it.

Aha, nice! What does it mean in more hands-on terms? It has been something
we've talked about and wanted to have for a very long time...

> I was surprised to find out that cookies are something that curl associates
> with connection handle.

It really doesn't.

> conceptually cookies are a url specific thing and not a connection
> handle specific. Rather than the api curl_easy_setopt(easyhandle,
> CURLOPT_COOKIE, cookie);
> following would have been a better interface....
>
> cookiejar = curl_cookiejar_init(filename);
> curl_cookiejar_setcookie(cookiejar, url, cookie);
> curl_easy_setopt(easyhandle, CURLOPT_COOKIEJAR, cookiejar);

The most recent "let's write a nice cookie API for libcurl"-discussion lead us
to this suggestion:

         http://curl.haxx.se/dev/COOKIES-new

I still think that would be a pretty good start for a new grand cookie API.

Cookies should be shared between multiple handles by the use of the share
interface. See details below.

> Does curl exposes api's to deal with the cookie store ?

No.

> Just setting cookies is not enough ?

Is that really a question? Yes it is enough for some. No it isn't enough for
some.

> I want to see what cookies are set for a given url, also I want to set
> cookies per url.

That would require a new API, yes.

> With the current api's, can anybody think of a better solution for
> associating cookies with urls rather than connection handles.

The current API does not offer good access to read or write specific cookies.

Let me explain a bit about the basics of the current approach:

libcurl doesn't associate cookies with "connection handles". The libcurl easy
handle (CURL *) is not connection-based, and it may in fact hold reference to
several different connections (each of those being a connection handle).

The easy handle is the only handle you have to connect cookies to a particular
request (or series of requests) so you will need to use that even in a future
improved API.

The shared interface approach however, is generally so that you first create a
"shared object" and you specify what data it should share. Then you apply that
object to an easy handle, and all of a sudden all the shared data that is
written or read is done on the shared object.

The shared object can then surive an easy handle and it can be shared between
multiple easy handles, even simultaneously from multiple threads if you just
set and use the lock/unlock callbacks properly.

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