On Wed, 1 May 2002, Roth, Kevin P. wrote:

> > o I thought it played nicely with the fact that -b already read cookies,
> > we only needed an option for writing as well.
>
> True. But other tools (thinking Eliza is one) simply have a flag that
> "enables cookies". It would be more browser-like (IMHO) to have curl treat
> a cookie-jar as a permanent cookies file (like netscape does), with an
> extra flag (as suggested below) to block reading session cookies. This
> would mean that -c both reads and writes (e.g. "keeps up-to-date") the
> cookie-jar file.
>
> However, I can live with 2 parameters instead of one (as it would probably
> break something to change this now) for historical reasons, as long as the
> documentation is completely clear.

Documentation is always a problem when I am the only one writing it, as I am
sometimes so deeply involved in the details and I know just about every quirk
there is in the code, which makes me sometimes leave out things that I find
obvious or sometimes I describe matters in overly complex ways. Also, my way
of (ab)using english leaves room for improvements. ;-)

> Understood. I guess what we need then is some simplification of the
> --manual text, along with a cookie-use FAQ... I will probably take a crack
> at the --manual updates, unless someone else wants to volunteer.

Based on experience, you can safely assume that no one will try to race you
on this issue! ;-)

I would LOVE contributions in that area. We could indeed use a separate
"cookie-use FAQ" or whatever we'll name it.

> Thanks. Two points of clarification please.
>
> 1: If -D is used on a request with multiple URLs (or with a -L) it appears
> that only the LAST set of headers is written to the file. Is there a way
> using only curl.exe parameters to get ALL headers recorded (either in
> separate files or by appending to the one file)?

I don't think my (original) intention was for this to do that. But you're
right of course, I checked the code in src/main.c and it resets the struct,
thus it causes the destination file to get re-created (and then closed) for
each loop.

I'd want it to create the file for the first usage and then close it after
the last usage. I think.

-L however, should work this way already. Repeated redirects make new headers
get appended.

> 2: If "-b headers" and "-D headers" are used together, along with multiple
> URLs,

I assume you're talking multiple URLs on the same command line here. Not
repeated invokes with different URLs.

> I'm going to take a guess at the order of things. Please correct
> it if I'm wrong:
> - curl reads from headers because of -b
> - then the first URL is requested
> - curl writes out the headers from this request because of -D
> - then the 2nd URL is requested (I'm assuming WITHOUT re-reading
> the headers file)

That isn't a correct assumption. Curl will load that header file between each
subsequent URL operation. It is basicly because the multiple-URL handling in
the client code loops around a massive amount of curl_easy_setopt() calls,
and all calls are made once for each URL. The particular call that makes the
-b file get read is too (CURLOPT_COOKIEFILE).

However, and here comes a fun trick, curl will *not* let a cookie loaded from
a file override a cookie that has just received from a server, even though
the file is loaded afterwards!

> One option is to block *reading* the session cookie from the cookie-jar
> file, which you understood from my previous message. The problem with this
> approach is simply that it's not very "browser-like", as a normal browser
> would have thrown away yesterday's session cookie at the point in time that
> the browser was closed (and the memory was flushed).
>
> So, to truly mimic a browser, we need a way to flush the cookie at the END
> of our session. We could introduce another option to prevent WRITING
> session cookies (which would be used on the request for page #2).

Ok, thanks for elaborating on the write-filter part, I follow the argument
now very well.

Yes, I agree that the filter-session-cookies-on-write thing is more "brower
like" but I kind of like the filter-them-on-read approach better. I don't
want both, since it is enough with one of them. When doing it on read, you
always have the ability left to decide if you want them included or not, and
in fact you can invoke several different command lines both using and not
using the stored session cookies using the same cookie file.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth_at_sourceforge.net