Does Zend Http Client Provide a Graceful Cancellation API?

Direct Answer

No. The Zend (Laminas) HTTP Client does not expose a cancel() method or any built-in mechanism to abort an in-flight request from application code. Once request() is called, the process blocks until the adapter returns a response or the socket-level timeout fires.

Confirmed Behavior

• No cancellation API exists in the client interface or any shipped adapter.
• Timeout is adapter-scoped: the timeout option is passed to the underlying adapter and governs socket read/write limits, not a global request-cycle timer.
• Curl adapter typically enforces the timeout for the entire request (DNS, connect, SSL, transfer).
• Socket adapter often applies the timeout only to individual read/write syscalls, so DNS resolution, redirects, and TLS handshakes can exceed the configured value.

Likely Explanation

The client was designed for synchronous, fire-and-forget use in traditional PHP request/response cycles. Because PHP historically lacks a standard event loop or thread model, there was no cross-platform way to signal an abort from another context. Adapters therefore rely on the OS socket layer, which behaves differently between libcurl and PHP's stream sockets.

Practical Workarounds

1. Use the Curl adapter when you need the timeout to cover the full request lifecycle.

   $client = new Zend\Http\Client($uri, [
       'adapter' => 'Zend\Http\Client\Adapter\Curl',
       'timeout' => 10, // seconds, applies to whole request
   ]);

2. Run the request in a separate process (e.g., via proc_open or a job queue) and terminate the child process if the parent decides to cancel. This isolates memory leaks and unstable state.
3. Set a low connect_timeout (Curl-only option) to fail fast on unreachable hosts.

   $client->getAdapter()->setCurlOption(CURLOPT_CONNECTTIMEOUT, 3);

4. Implement application-level timeouts with pcntl_alarm (CLI only) or set_time_limit, but be aware these kill the entire script, not just the HTTP call.

Adapter Comparison Table

Phase	Curl Adapter	Socket Adapter
DNS resolution	Covered by timeout	Usually not covered
TCP connect	Covered	Covered per read/write
TLS handshake	Covered	May exceed timeout
Redirects	Covered (total time)	Each hop resets timer
Body transfer	Covered	Covered per chunk

One Diagnostic Detail Needed

Which adapter are you currently using, and does your workload involve long DNS lookups, many redirects, or slow TLS handshakes? The answer changes whether switching to the Curl adapter alone solves the problem or whether you need process isolation.