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