cURL / Mailing Lists / curl-users / Single Mail

curl-users

Re: multiple session cookie handling

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Thu, 21 Jun 2001 14:53:04 +0200 (MET DST)

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!]

> I think updating and re-loading a distinct 'cookie jar' is a good idea,
> certainly simpler than messing with output headers and recyclying files
> over and over.

I agree.

> On the implementation side, I think curl would need to save both
> persistent and session cookies in the jar between executions, as the curl
> process doesn't live long enough usually to make use of the cookies
> otherwise. An option to 'flush' the jar of session cookies would be
> needed in this design.

I agree.

We need a way to decide if we want "single session" cookies, _after_ that
they've been saved. I think the option should be for the load, to tell curl
if you want the current invoked curl to use "session-cookies" from previously
invoked curl sessions or not.

The reason I want it in the load, and not the save, is that scripts might
very well be written that makes this kind of single shots and then after
having analyzed the data it received, knows whether it should (appear as if
it still) maintain the same session.

> 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.

> 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.

> Library issues - Ideally the library would provide callbacks for either
> loading the jar into memory and writing the jar back, with some structure
> passed back and forth, then a busy application could keep the jar in
> memory or database and cut out the disk overhead for the jar for each
> request.

Sounds like a good idea. We could possibly offer a default cookie jar
handler.

> 'curl' can use the callback to read/write the physical jar in its chosen
> format (netscape/mozilla?)

I've been thinking about the file format. I don't like introducing file
formats. I always regret the design later on... :-)

So, the netscape format (also used by Mozilla) has several advantages and a
few disadvantages.

PRO:
 - we can easily exchange cookies between curl and a browser, even after curl
   has updated them
 - it is an existing format that other tools may recognize and be able to
   work with

CON:
 - it may lack data fields that we could benefit from having. I haven't
   quite thought this through.
 - locked format, we can't expand it in the future

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

> What might be nice might be a callback to decide if you actually want to
> keep a particular cookie in the jar as its passed back to curl from the
> site, or at least flags to say what you think of cookies from a
> particular site (or a list of preferences in a file). Session cookies are
> usually OK, persistent often bad, etc. etc.

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.

> 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). ;-)

-- 
     Daniel Stenberg -- curl dude -- http://curl.haxx.se/
Received on 2001-06-21