> >> Do you have any further thoughts on how we should deal with
> >> documentation
> >> (and possibly testing) of what info that can be fetched when?
> >
> > I would suggest dividing CURLINFO items into two groups,
> > those are derived from headers, and those that a updated
> > during the transfer of the body.
> >
> > It would be nice if any info that is derived from a header
> > were available no later than when libcurl sent the last
> > (empty) header line to the application, i.e., in the callback
> > that processes the last empty header line, it would be legal
> > to call curl_easy_getinfo() to retrieve items derived from
> > the headers.
> >
> > If that were the nominal rule, then the exceptions to that
> > rule could be documented. (What I'm saying BTW may be pretty
> > HTTP specific and I'm not sure how it would apply to other protocols.)
> >
> > As you mention, that you save you from having to parse the
> > headers yourself, at least to the extent that libcurl is
> > parsing the headers you are interested in.
>
> Yes, that sounds like a good plan to me. Can you please provide your
> CURLINFO_CONTENT_LENGTH_DOWNLOAD change in diff -u format?

Patch enclosed and attached.

Note there are at least two places that Curl_pgrsSetDownloadSize is called
in the existing code. I believe that with this patch, these calls would be
redundant/superfluous/unneeded, but I haven't tried removing them.

Allen

------------------

diff -w -u C:\sources\curl-7.16.2\lib/transfer.c ./transfer.c
--- C:\sources\curl-7.16.2\lib/transfer.c 2007-06-21
14:53:58.324866600 -0400
+++ ./transfer.c 2007-06-28 21:15:45.870207300 -0400
@@ -849,6 +849,7 @@
               if(contentlength >= 0) {
                 k->size = contentlength;
                 k->maxdownload = k->size;
+ Curl_pgrsSetDownloadSize(data, k->size);
               }
               else {
                 /* Negative Content-Length is really odd, and we know it