Sorry, forgot to include the reference for [1] -
https://tools.ietf.org/html/rfc7231#section-7.1.2

Ryan

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

> On Wed, Mar 28, 2018 at 11:57 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
>
>> 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.
>>
>> 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
>

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-04-04