Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Asynchronous certificate verification and curl_multi
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Ondra via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 13 Aug 2025 16:31:54 +0200
On Wed, Aug 13, 2025 at 3:16 PM Daniel Stenberg <daniel_at_haxx.se> 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...
Date: Wed, 13 Aug 2025 16:31:54 +0200
On Wed, Aug 13, 2025 at 3:16 PM Daniel Stenberg <daniel_at_haxx.se> 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.htmlReceived on 2025-08-13