On 4/3/2018 7:54 PM, Ryan Braud wrote:
> On Wed, Mar 28, 2018 at 11:57 PM, Daniel Stenberg <daniel_at_haxx.se
> <mailto: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
> <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 :)

You can use libcurl's CURLINFO_REDIRECT_URL [1] or curl's --writeout
%{redirect_url} [2]. If http://foo.bar/ has a redirect like:

Location: qux

the redirect url you would get is http://foo.bar/qux. In other words
libcurl should give you an actual url. You can reuse the same handle but
to your point about auth you may not want to send the auth from the
previous transfer. If libcurl were handling the redirect then the
default would be not send the auth if the hostname is different, and
that could be overridden with CURLOPT_UNRESTRICTED_AUTH [3]. However,
because you are doing it manually you would make that determination
yourself if necessary. For example extract the hostname from the url and
if it's different then turn off auth. Two other things I would do is
limit the number of redirects to prevent a bad redirect loop and check
the response code to make sure it's 3xx. Use CURLINFO_RESPONSE_CODE [4]
like if (redir_url && code / 100 == 3) {check max redirects, disable
auth if necessary, set url, goto again}

The documentation should be clarified to explain how the timings work
with redirects. starttime for example says from the first byte but does
not say what happens with redirects. so it strikes me as ambiguous.

[1]: https://curl.haxx.se/libcurl/c/CURLINFO_REDIRECT_URL.html
[2]: https://curl.haxx.se/docs/manpage.html#-w
[3]: https://curl.haxx.se/libcurl/c/CURLOPT_UNRESTRICTED_AUTH.html
[4]: https://curl.haxx.se/libcurl/c/CURLINFO_RESPONSE_CODE.html

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