This is just a tracking case right now. The background is here which is a case in github against curl
Someone noticed that shib "slows down" dependant on the curl version, with the offending checking being this http-proxy: do the HTTP CONNECT process entirely non-blocking
Discussion in the case is pointing our way Daniel (curl author) says:
This sounds like at least partly a shibboleth issue. libcurl itself hardly waits for 2 seconds somewhere.
I suspect the source for this is because when the multi interface is used, a threaded-resolver build doesn't have a socket to return back during the name resolving phase. So the user of libcurl needs to wait for a short while and then call again, in a polling manner. That's not necessary with the non-threaded resolver since then this phase of "no socket" doesn't exist - the name resolving is then done entirely synchronously (or you'd build to use c-ares to resolve names asynchronously, but c-ares would then have a socket to wait for)...
So yes, the next step is clearly to understand how libcurl is invoked and the logic around how/when it gets called again.
My preference is to keep the case over in git for now, but if it turns out to need attention by us this case is for it.