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.

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). But because curl is often used for one page request at a
time, and gets called multiple times during one "session" (so that our
batch scripts can look at the intermediate output and decide what to do
next), it wouldn't always work for curl to actually store session
(temporary) cookies in memory.

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

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

--Kevin
Received on 2001-06-20