On Wed, 28 Mar 2018, Ryan Braud wrote:

> I just wanted to write and say that I really, really, really wish you had
> not done this.

Welcome to this *colloborative* project we call curl.

This change you refer to (for the rest of the audience), being the commit
https://github.com/curl/curl/commit/43d036e7 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.

> Please reconsider this change and revert this behavior to the way it was
> before.

That ship has sailed.

I try *really really* hard to always make the right decisions for the library
to work correctly for our users (and man, we have many many users and I spend
enormous amounts of time on this) and do have as few surprises as possible.
This is many times a very lonely job because even if I ask, people often don't
respond and then I need to proceed and act on my instincts. Every little
change and bug fix risk breaking something in an application somewhere that
depends on the former behavior.

A collaborative effort works better when it is, yes, a collaboration. Just
leaning back and hoping that the project will make decisions that always are
in your favor is asking a lot. If you don't participate, there will be moments
in time when decisions and changes are made that go against what you think is
the right way. You're welcome to sit back and enjoy the ride, but then you
have to accept that some road forks will be taken in the direction you
wouldn't have wanted.

All that said, even if this particular ship sailed almost a year ago and we
can't make it come back, we should rather discuss what we *can* do to offer
this functionality that you want or what you can do to still get the numbers
you're looking for.

As an immediate work-around, you might be able to switch off FOLLOWLOCATION
and instead do the redirect following manually with the use of
CURLINFO_REDIRECT_URL and then you can extract the timing for each redirect
step without getting them sumed up.

For a more long-term fix, or solution, I wonder if we should introduce new
timers that are specificly only for the last transfer in a redirect-chain.

What do you think?

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html