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.

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.

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

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. 'curl' can use the callback to read/write the physical jar
in its chosen format (netscape/mozilla?)

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.

Sorry, no commitment to implement on my part at the moment, but I'd like
to pass my ideas onto someone with current enthusiasm...

Cris

Dustin Boswell wrote:
>
> >On Wed, 20 Jun 2001, Roth, Kevin P. wrote:
> >Considering how difficult the current cookie handling can be for someone
> >who isn't familiar with it, I suggest patching to require only one
> >argument. Perhaps
> >
> > curl --enable-all-cookies cookies.txt
> >
> >where one file (cookies.txt) is responsible for storing all cookie info,
> >and the user doesn't have to keep track of when to dump headers
> >(cookies) into a file and when to simply read them from an already
> >existing file.
>
> That's a good point, although I can imagine situations where I'd want
> to have the "before" and "after" cookie information in (possibly)
> different files so that I can "re-enact" the scenario by sending the
> old "before" cookies again. But an advanced user could do this
> by backing up files, instead of needing a curl option. I agree then. :)
>
> >The only difference at this point between a "typical" browser and curl
> >is that a typical browser makes a distinction between session cookies
> >(in memory only, discarded when you quit out of the browser) and
> >permanent cookies (written to disk, persisted from one browsing session
> >to another).
>
> I'm a bit confused. How does a server send a "session-only" cookie?
> Aren't all cookies supposed to be the permanent kind? Or are you
> talking about the way a browser handles a cookie? Even so, how would
> it determine which cookies should be thrown away when the user quits?
>
> >If we wanted to get fancy, we could emulate browsers even better with a
> >total of three options:
> >
> > 1) curl --enable-all-cookies cookies.txt
> > 2) curl --enable-session-cookies sess-cookies.txt
> > 3) curl --enable-persistent-cookies pers-cookies.txt
> >
> >where #1 stores ALL cookies in one file (for maximum ease-of-use), and
> >#2 & #3 store just one of the two types of cookies in separate files (so
> >we could decide when our session is finished by deleting the
> >sess-cookies.txt file).
>
> I guess I'll understand what you mean when I understand the previous
> comment. :)
>
> >It would probably also be good (for backwards compatibility, and also
> >for those who are more comfortable using the "old" method) to keep the
> >old methods around. So there would still be an option to just read
> >cookies from a pre-created cookies (or headers) file, and an option to
> >dump all headers into a separate file.
>
> yes, I agree
>
> >As well as the option to just
> >enable cookie parsing (-b non-existant-file.txt?) so that a single curl
> >call with multiple URLs can maintain cookies in-memory without having to
> >be able to write a file to disk...
>
> hmm, I guess I never really thought about it before, is that
> (-b non-existant-file.txt) how we're supposed to do that now?
>
> -Dustin.
Received on 2001-06-21