On Sat, 8 Nov 2014, m brandenberg wrote:

> LOW_SPEED_LIMIT is still useful. Or would be except that pipelining has
> split the request and response phases of a request. The gap between these
> two can be fairly long on a healthy connection and that gap will be included
> in calculations.
>
> Proposal: break application of LOW_SPEED_LIMIT into two phases: request
> and response. Disable and reset working counters/times between the phases.
> Document appropriately.

My general response to all requests for different and new timeouts is that we
offer callbacks and information about transfers enough to allow applications
that want fancier or more complicated ways to timeout the powers to do their
own timeout logic that fits their needs better.

Of course if we identify general areas that lots of users are likely to want
improvements we can indeed introduce new options and things, but like in this
case we're talking about a fairly limited use case of checking transfer speeds
on pipelined requests and only do that after the download has started. Isn't
this something that the application is better of handling itself so that it
gets the perfect granularity and adaption for this use case rather than to
introduce an option to the general libcurl?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html