On Sat, 1 Sep 2001, jonatan wrote:

> >That is the correct behaviour. libcurl outputs a stream of data, it can't go
> >back and erase what has already been written.
>
> why not? couldn't libcurl ftell() before the first header set and fseek()
> there before each following header set? at least as an option.

Uh, right. If the headers were always written to a file, that would indeed be
possible. Now, the output could just as well be stdout or sent virtually
*anywhere* thanks to the write callback functionality.

> >If you're only interested in the last set of headers, you probably add a
> >header-receiving callback that filters out everything but the interesting
> >parts.
>
> i'll try that. (i see a potential problem where i wouldn't know what was
> a header set and what wasn't. suppose the body contains a header set of
> it's own (as if i had tried to access the file "out" from my example thru
> http). how do i know it's not a real header set...

If you check out the CURLOPT_HEADERFUNCTION option, I'm sure you'll notice
that you won't need to figure out if it is a header or not. You would only
need to figure out if the particular header line is what you want or not.

> libcurl knows it internally, but i'm not sure it's possible to deduce
> that afterwards. or perhaps the http spec has solved this somehow.)

Yes it does, but you won't need to go into those details. You might need to
understand that a header is ended with an empty CRLF line. (So that's gonna
be what separates multiple headers when libcurl follows locations.)

> > > btw, the docs/examples/*.c files seem to lack curl_global_*() calls.
> >Yes, you're right and I'd appreciate patches that correct this!
>
> i would if i had any idea how to make patches...

 diff -u originalfile newfile > patchfile

Preferably, you use a GNU diff. Older diffs don't support -u, and then -c is
fine.

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/