Daniel,

This looks very nice to me..

And there is an explicit verb for saving to a specific file at some time :)
.. witch I had to hack a while ago to work with persistant connections.

If I undestand correctly : a cookie-jar will be mapped in memory (list of
curl_cookie structs) for edition. The API seems ok to me (very cUrl-ish ;)
Although it might be worth some basic 'default' automation, I mean : derive
a cookie-jar filename from the request to save all cookies related to the
document.. I read the FUNC spec and I'm not sure if this is what you ment by
'proceed as normal'.

Lo.

----- Original Message -----
From: "Daniel Stenberg" <daniel_at_haxx.se>
To: "libcurl Mailing list" <curl-library_at_lists.sourceforge.net>
Sent: Wednesday, June 18, 2003 4:48 PM
Subject: cookie interface suggestion

> Hi
>
> Every now and then someone figures out that applications don't have very
much
> control of what cookies libcurl receives or sends away. You pretty much
have
> to let it control all cookies as it sees fit, or no cookies at all. If
> libcurl handles the cookies, the application doesn't know which cookies
that
> exist.
>
> So, without rushing into anything, here follows my suggested approach on
how
> to add a cookie interface to a future libcurl.
>
> This work depends a whole lot on your feedback.
>
>
/***************************************************************************
*
> libcurl cookie interface suggestion draft
> Date: 2003-06-18 */
>
> /* This is the cookie struct used for all communication in/out of libcurl.
It
> * will not be used internally, but only for representing a cookie that is
> * known and stored differently within libcurl.
> */
>
> struct curl_cookie {
> struct curl_cookie *next; /* if non-NULL, points to the next cookie */
> unsigned char *name;
> unsigned char *value;
> unsigned char *domain; /* or NULL */
> unsigned char *path; /* or NULL */
> bool secure;
> time_t expires; /* 0 means "session-cookie" */
> void *hidden; /* refers to the corresponding cookie information
> held by libcurl in the curl handle memory */
> };
>
>
/* ------------------------------------------------------------------------
>
> curl_easy_cookie(CURL *handle,
> CURLCOOKIE option,
> ...);
>
> Options include:
>
> SAVE - write down all cookies to the specified cookie jar now.
>
> LOAD - load new cookies from the specified file
>
> ADD - pass a pointer to a curl_cookie struct, of the cookie to add. All
> info
> will be copied from the struct.
>
> DEL - given a libcurl cookie 'hidden' pointer (see the cookie struct),
the
> corresponding cookie is removed. If NULL is given, ALL known
cookies
> are removed.
>
> GET - TWO ARGUMENTS required!
>
> First argument: Pass in a pointer to a curl_cookie struct. The
> cookie(s) matching the given information is returned in a linked
list
> of curl_cookie structs, stored in the pointer the second argument
> points to. Example:
>
> struct curl_cookie mystruct; [fill in]
> struct curl_cookie *results; [get results here]
>
> curl_easy_cookie(curl, CURLCOOKIE_GET, &mystruct, &results);
>
> If the first argument is NULL, all known cookies will be returned.
>
> Will the data pointers be pointing to internal strings or are they
> separately allocated? It affects how applications can use the
> strings.
>
> This will probably require a separate FREE operation to free an
> earlier retrieved list of cookies. Consider how.
>
> FUNC - set a function pointer that is called each time a cookie is
received
> from the network by libcurl, the function should match this
> prototype:
>
> int func(CURL *handle, struct curl_cookie *cookie, void *userp)
>
> By returning 1, libcurl will not store the cookie. Returning 0
will
> make libcurl proceed as normal. (Other return-codes are considered
> reserved for future use.)
>
> DATA - set whatever userdata you want the FUNC callback to receive in its
> userp argument.
>
>
>
****************************************************************************
/
>
>
> --
> Daniel Stenberg -- curl: been grokking URLs since 1998
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: INetU
> Attention Web Developers & Consultants: Become An INetU Hosting Partner.
> Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
> INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
>
>

-------------------------------------------------------
This SF.Net email is sponsored by: INetU
Attention Web Developers & Consultants: Become An INetU Hosting Partner.
Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission!
INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php
Received on 2003-06-19