On Thu, 21 Mar 2002, Jacky Lam wrote:

> > Until that works, you can store the files separately and then "merge"
> > them yourself before passing them on as input to the following requests.

> Yes, I also think about using separate files. However, managing
> cookies(merging, eliminating,....) with text file operations is too trouble
> and the overhead is too high. So, I am now creating a global cookie list in
> memory using the library functions directly. Although I am not testing it
> hardly, it seems work.
> BTW, is the cookie functions in cookie.c MT safe?

No. As long as libcurl doesn't do mutexing, it can't share data between
several running threads. You can't manipulate a single list for multiple
threads and do it MT safe, without mutexes.

> > Again, I'm all ears for suggestions on how this can be improved in future
> > releases.

> However, having a callback funciton upon redirect?

You mean a callback that would then allow your code to add whatever headers
you think fit?

It makes it kind of complicated. I actually think that if you really want to
mess around with your own headers, then I think you can be left to parse
Location: headers yourself.

An alternative could be to have a function in libcurl that parses Location:
stuff and returns the new URL, and then you can do the request to that URL
yourself. Hm, yes I think I'd like that... :-)

> Also, an alternative to store cookies in memory is useful.

The cookies are of course stored in memory all the time, they're only saved
to a file when you have told libcurl to do so.

We've been talking about this before. We might need to offer an interface to
the existing cookies, to enble an application to extract cookies, to replace
cookies, to alter cookies. We just haven't actually discussed any API or got
any real-life suggestion on specific implementations.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/