On Thu, May 15, 2014 at 11:39 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> I think this can be clarified somewhat. I would like it to say that it
> counts the number of bytes considered part of the "payload", "body" or
> "data" or whatever generic name we use to identify the data that is meant
> for the application. All meta information and headers excluded.
>
>
I definitely agree that header data shouldn't be counted there, but in my
opinion, the overhead of chunked encoding is part of the body -- they are
bytes sent in the "body" of the HTTP response, after all.

 So, I thought this would be the # of bytes transferred over the wire for a
>> request. However, when using CURLOPT_WRITEFUNCTION and comparing the
>> number of bytes passed to it with the value returned from
>> CURLINFO_SIZE_DOWNLOAD, they are the same, even if the response was
>> returned with chunked encoding. Shouldn't the wire size of a chunked
>> response be different than the actual page size, due to the encoding
>> process?
>>
>
> I think that would cause problems with those existing applications that
> made assumptions like in the style I mentioned above.
>
> We already separate the header size with CURLINFO_HEADER_SIZE and even if
> it isn't quite clear how we'd count chunked-encoded meta-data I would
> rather have us count that as headers rather than body.
>

You're right that it probably can't be changed now for backwards
compatibility reasons. But I would also not want those bytes to show up in
CURLINFO_HEADER_SIZE either. In the end it's not a huge deal because the
overhead is usually low, and I only ask because I try to get as accurate
values as possible for estimating the throughput of a transfer, etc.

It does seem that using CURLOPT_DEBUGFUNCTION and counting CURLINFO_DATA_IN
gives me ALL the (non-header) bytes received though, including the bytes
for chunked meta-data. Is this correct?

Ryan

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-05-16