On Tue, Dec 10, 2013 at 07:52:33PM +0100, Daniel Stenberg wrote:
> On Tue, 10 Dec 2013, Mohammad_AlSaleh wrote:
>
> You didn't mention which libcurl version on which platform you're using!
>

7.33.0 (GNU/Linux x86_64)

> >A small test case is attached to help me explain. It's not a real-world
> >use case.
>
> CURLOPT_MAX_RECV_SPEED_LARGE on a file:// URL is not supported, and
> not a good idea. Although it also shouldn't harm anything.
>

It doesn't make sense anyway. I just used it to exaggerate the effects
of the behaviour I'm trying to describe.

> >1- All required data is read fast.
> >
> >2- dlnow will report a completed transfer early on.
> > (It only represents the size of data received/read).
> >
> >3- Not all data is flushed after writes
> > (unless you uncomment the fflush line).
> >
> >4- libcurl will keep waiting until the speed limit is met on a now
> > long interval.
> >
> >5- Finally, the remaining (unflushed) data is written.
>
> Apart from (4), isn't that the exact same procedure as without
> CURLOPT_MAX_RECV_SPEED_LARGE? That waiting certainly sounds like a
> bug.
>

Yes. That's the point I was trying to make. It waits even if there is no
more data to read.

> And libcurl never flushes the output, it shouldn't need to. If you
> want that done, use a callback and add whatever you think is
> necessary!
>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2013-12-10