🚀 go-pugleaf

Thanks Remy

"Remy Lebeau (TeamB)" <no.spam@no.spam.com> wrote in message 
news:41c93d7b$1@newsgroups.borland.com...
>
> "Ted Tripp" <ttripp@rankexec.com> wrote in message
> news:41c90294$1@newsgroups.borland.com...
>
>> I am running into a situation where, when doing a Get on a particular
> page(s),
>> the data comes in chunks.
>
> That is likely if the content is large.
>
>> In other words the WorkStart event occurs maybe ten times for a
>> single page, thus causing the OnWork to occur 10+ times on the
>> same page.
>
> OnWork is usually triggered in a loop by Indy reading data streams in
> fixed-sized pieces internally.
>
> If you are getting multiple OnWorkBegin events, it is likely that the HTTP
> server itself is sending the data in multiple blocks rather than one
> continuous stream (the "Transfer-Encoding" header is set to "chunked").
> Thus TIdHTTP has to read the data in multiple blocks and then piece them
> back together.  Each block would have its own set of
> OnWorkBegin/OnWork/OnWorkEnd events being triggered, because TIdHTTP has 
> no
> way of knowing ahead of time how much many blocks are being sent or how
> large each block is.  The OnWork event will not provide an accurate count,
> though, because TIdHTTP will be calling ReadLn() during a chunked 
> transfer.
> ReadLn() triggers OnWork as well, so the total reported count will not be
> the same as the Size of the data actually being returned to you in the 
> final
> response.
>
>> Is this a result of the RecBuf size I set
>
> No.  The triggering of the OnWork events is directly related to how the 
> data
> is being transferred, not how large the data is.
>
>> and if so, how do I get an accurate total of data received.
>
> You could query the TIdHTTP.Response.ContentStream.Size property during 
> the
> transfer.
>
>
> Gambit
>
>