cupertino_http's CupertinoClient doesn't currently expose any way to customize TLS server trust evaluation — there's no hook equivalent to URLSessionDelegate's urlSession(_:didReceive:completionHandler:) for the NSURLAuthenticationMethodServerTrust case.
Use case: Certificate pinning against a CA higher up the chain than the leaf. For example, AWS explicitly recommends pinning to an Amazon Trust Services root CA (not the leaf, and not even the intermediate CA) for ACM-issued certificates, since Amazon now issues from multiple "dynamic" intermediate CAs that can rotate unpredictably — see AWS's own guidance: https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/. Implementing this requires walking the full certificate chain during the TLS handshake to find the pinned CA, which dart:io's HttpClient.badCertificateCallback cannot do — it only exposes the leaf certificate via X509Certificate, never the intermediates or root.
cupertino_http is otherwise a great fit for this — it already streams request/response bodies properly via URLSession's native APIs, unlike dart:io's HttpClient. The only missing piece is a way to intercept the trust decision.
Proposed API (minimal surface, doesn't require exposing the full delegate):
CupertinoClient.fromSessionConfiguration(
config,
serverTrustEvaluator: (SecTrust trust, String host) => bool,
);
cupertino_http would still own the actual URLSessionDelegate internally (preserving its existing streaming/redirect handling); it would just call this closure during its own didReceive challenge implementation and act on the returned decision.
Happy to contribute a PR if the maintainers are open to this direction.
cupertino_http'sCupertinoClientdoesn't currently expose any way to customize TLS server trust evaluation — there's no hook equivalent toURLSessionDelegate'surlSession(_:didReceive:completionHandler:)for theNSURLAuthenticationMethodServerTrustcase.Use case: Certificate pinning against a CA higher up the chain than the leaf. For example, AWS explicitly recommends pinning to an Amazon Trust Services root CA (not the leaf, and not even the intermediate CA) for ACM-issued certificates, since Amazon now issues from multiple "dynamic" intermediate CAs that can rotate unpredictably — see AWS's own guidance: https://aws.amazon.com/blogs/security/amazon-introduces-dynamic-intermediate-certificate-authorities/. Implementing this requires walking the full certificate chain during the TLS handshake to find the pinned CA, which
dart:io'sHttpClient.badCertificateCallbackcannot do — it only exposes the leaf certificate viaX509Certificate, never the intermediates or root.cupertino_httpis otherwise a great fit for this — it already streams request/response bodies properly viaURLSession's native APIs, unlikedart:io'sHttpClient. The only missing piece is a way to intercept the trust decision.Proposed API (minimal surface, doesn't require exposing the full delegate):
cupertino_httpwould still own the actualURLSessionDelegateinternally (preserving its existing streaming/redirect handling); it would just call this closure during its owndidReceive challengeimplementation and act on the returned decision.Happy to contribute a PR if the maintainers are open to this direction.