curl / Mailing Lists / curl-library / Single Mail


Re: accumulated timers (was RE:

From: Ryan Braud <>
Date: Tue, 3 Apr 2018 16:54:47 -0700

Sorry, forgot to include the reference for [1] -


On Tue, Apr 3, 2018 at 4:54 PM, Ryan Braud <> wrote:

> On Wed, Mar 28, 2018 at 11:57 PM, Daniel Stenberg <> wrote:
>> Welcome to this *colloborative* project we call curl.
>> This change you refer to (for the rest of the audience), being the commit
>> was the final step in a
>> very long going discussion and review of the patch that was ultimately
>> merged (by me).
>> The timing issue it addressed was listed in KNOWN_BUGS from April 2016
>> until this patch was merged in June 2017.
>> A rather long progress I would say, with ample opportunities for anyone
>> to object, discuss, suggest different approaches or just say that current
>> approach works fine.
>> Nobody objected to this change. Not a single person (until now) has
>> complained about it since it was merged in June 2017 (shipped in curl
>> 7.56.0). In fact, I believe a few users even appreciated the fix.
>> While I understand your position here, I really don't think it's
> realistic to expect everyone who uses curl to be subscribed to this mailing
> list and be able or even willing to comment on whether some change is
> appropriate or not. In my opinion, this should have been treated as any
> other breaking change (which you are pretty good about not introducing) and
> not touched. Your suggestion to me was to implement redirects ourselves if
> that is the behavior we want. We have been forced to go this route, trying
> to make this change as quickly as possible in order to un-break data we are
> showing to our customers which now does not make sense. But please realize
> that doing this is non-trivial for many reasons. Correctly following a
> redirect in the presence of relative URLs is complicated (see [1]). Not
> forwarding authentication headers to different hosts after a redirect is
> another complication. There may be other cases that we now need to think
> about and handle and we will almost certainly get something wrong and be
> forced to go back and tweak it.
> I realize that this is the reality of the situation so I'm not going to
> try to convince you to change things back to the way they were. But I do
> think it would be extremely helpful to have an API for retrieving timing
> data for every request directly from curl because forcing people to
> implement redirects to get it is quite painful. And please try not to make
> any more breaking changes that aren't true bug fixes :)
> Ryan

Received on 2018-04-04