Daniel Stenberg wrote:
>
> On Thu, 21 Jun 2001, Cris Bailiff wrote:
>
> [I'm trying to do some brainstorming, stating ideas and thoughts here. Feel
> free to object, complain or improve them!]

...snip....

> > Another useful feature would be to make sure the jar is shareable - that
> > is, curl should do a 'exclusive-lock, read, update, write, unlock' cycle
> > on each update access, so that multiple curls can safely share the jar,
> > even when end sites are setting their own cookies per-request.
>
> We *could* do that. Although, it sounds like a thin path to walk on, as you
> wouldn't really know which curl that would save their view of the cookies
> last, and thus has the final "say" about things.

The last curl to write - the point is that the atomic action is the 'add/update'
of a single cookie - you load the jar,update relatvie to the loaded jar and write
back inside the lock, so that any other updates can't 'race' you. There is only a
race if two simultaneous curls update the same cookie (same name, host/domain,
path triple) - then the last one wins, which is the same as if two simultaneous
pages set the same cookie in a normal browser. Otherwise, non-colliding cokoies
all collect safely in the jar without there being any 'lost updates'.

> > This would let you script a login with one curl instance (to get a
> > session cookie, for example), then fire off multiple simultaneous
> > downloads or other accesses without worrying that one or other would
> > clobber the jar for other sessions (nasty race, otherwise).
>
> This particular example could also be done by simply having the initial login
> curl put its cookies in the jar, and then the download curls would use that
> jar read-only (as -b works today). It would also make it a lot easier to
> understand in what state the cookie jar is in, at any given moment.

Except mayebe each subordinate curl needs to track new cookies/session state as
it goes - for example, to talk 'hotmail', you need to peddle hard with cookies,
redirects etc. You're initial login set of cookies is a good start, but then
perhaps you'd like to download multiple mail messages simultaneously - hotmail
still tends to throw cookies at you, seemingly almost at random, and sulk when
you don't give them back. You need to carefully simulate a real browser to get
through OK.

> Another well established format we *could* use, is storing them as they would
> appear in HTTP response headers. This has a few advantages and a few
> disadvantages as well of course.
>
> PRO:
> - flexible format, new fields can easily be added
> - curl understands this format for reading already
>
> CON:
> - impossible to exchange with a browser or other cookie file tools

CON: the header file format doesn't record which site the cookies came from, in
the case of 'default domain' cookies - if the server doesn't set a domain
attribute on the cookie, you don't know where its from, which prevents you
storing multiple different site cookies in one file. The current parser login
assumes one file/header-set per site.
 
> Well, if the writing of the jar would be done with a callback system where
> libcurl would pass the information to a custom function, then of course that
> function could just not write whatever cookie it considers isn't fit for
> writing.

Yeah, that would work, but that means the client program has to work out where in
the jar to keep the cookie. Does this imply that the client is responsible for
deciding which cookies from the jar should be applied to each request? If not,
then we need two callbacks - one to add cookies to the jar and one to pass the
whole jar back in for using in the next request - which aren't very symetrical.
Thats why I suggested this separately from the load/save jar calls...

> > Sorry, no commitment to implement on my part at the moment, but I'd like
> > to pass my ideas onto someone with current enthusiasm...
>
> If no one else volounteers, we'll be able to talk it through thoroughly until
> I get time to hack on this (in August). ;-)

I'm currently using the perl HTTP::Cookies library to load and save my cookies,
by grabbing the raw headers from Curl::easy into the jar for save, and making a
fake 'HTTP::Request' for HTTP::Cookies to fill from the jar, and then copying
from HTTP::Request to the curl_request for the load. I'd like to simplify/speed
this up if I could...

Enjoy your trip....

Cris