On Wed, Aug 13, 2025 at 3:16 PM Daniel Stenberg <[email protected]> wrote:
> > Shouldn't the callback pause the transfer when it can't verify the > certificate > right now but thinks it will magically have information in the future. > > Then in a future when it has the information it resumes/unpauses the > handle > again? > > I am not sure. Curl could handle SSL_ERROR_WANT_RETRY_VERIFY as the pause command and we could add an explicit command to resume. But I am testing how it behaves and it seems that from within the invocation of curl_multi_socket_action() which triggers the initial cert verify callback, it sometimes happens (timing?) that the current implementation already invokes the cert verification callback for the second time (spuriously). If we would consider random spurious invocations of this verification callback as acceptable, then it may be feasible to not have any explicit resume command and keep the resumption on the provider of the multi loop completely outside of curl by eg. hanging the processing of the easy handle on next invocation of curl_multi_socket_action with CURL_SOCKET_TIMEOUT or CURL_SOCKET_RETRY_CERT or something like that (not sure how to do it in curl_multi_perform though...); if events on unrelated fd s reported via curl_multi_socket_action do not trigger it, then the spurious callback invocations could be sufficiently rare for this approach to be efficient enough. Saying this, it is not very pretty from interface design perspective...
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
