Apologies in advance for the longish message. As you probably
know, I tend to ramble a bit...

-----Original Message-----
From: Daniel Stenberg [mailto:daniel_at_haxx.se]
Sent: Wednesday, May 01, 2002 7:07 AM

> Actually, -c doesn't _read_ cookies. It only writes them.
> -b understands both header-style and cookiejar-style input files.
> That's why "-b file -c file" actually makes a pretty good
> combination in many cases.

I stand corrected... I was under the impression -c had been added
to eliminate having to use multiple cookie parameters to make cookies
"just work". I know *personally*, when I use a real-life cookie jar,
I never just remove (read) and add (write) cookies; I also consume
(parse) them ;-)

Is there any reason why -c *shouldn't* enable cookie parsing and
also read (and use) any pre-existing cookies? If the desire was
to produce a "static" cookie-jar file, and then just use it without
updating, -b could still be used. But if the goal is to mimic a
browser session, then -c would be the only param needed. I can't
think of any example where a cookie-jar file would need to be
created, but not used...

If there *is* such a reason, then my problem is that it seems
counter-intuitive to specify the cookie-jar file twice (once for -b,
and once for -c). One simple fix might be to add a magic filename
for -b, that simply tells curl to use whatever file is specified
for -c. So, if the special "filename" is "@", you could do this:
  curl -b @ -c cookies.txt url://...
which specifies a cookie-jar file, and also enables the cookie parsing,
using the cookie-jar contents as initial input, but without inputting
the cookie-jar filename twice...

Can someone draw (ascii is fine) a timeline of how the -c, -b and -D
parameters work together? In other words, given this command line:

  curl -c cookies -b headers -D headers http://host/f1 http://host/f2

when do each of the files get read and/or written (relative to each
other and also to making these two requests), and what contents go
into each? Also show what happens in memory, with the cookies
coming back from the web pages.
Assume /f1 sets a cookie named "c1" with some value, and /f1 sets
a cookie named "c2" (and perhaps also "c1" if that's interesting).

> No. The so called "session" cookies will be stored in the cookie jar
> when -c is used, in the same way all other cookies are stored. As curl
> is often used with multiple invokes to simulate a single session, it
> made most sense (to me).
> I think we could instead consider adding an option that prevents
> such cookies from being read/used from a given input.

I propose -j/--junk-session-cookies, which, when combined with -c
or -b, would prevent session cookies from being read out of the
cookie-jar or headers file. It would however, still store NEW
session cookies in the cookie-jar file or the headers file, and it
will also USE any new session cookies in subsequent requests (-L
or multiple URLs).

This way, there are two ways to "clear out" session cookies. One is
to make a request for a non-existant file (e.g. /dev/null) at the
*end* of a curl "session" (netscape and IE also remove their
session cookies at the end of a session, but that's because they're
in-memory only). The other is to use this option on the *first*
call at the start of a new curl session; in this scenario, you
have to save any NEW session cookies which are generated, but you
want to explicitly trash any old ones.

--Kevin
Received on 2002-05-01