HttpClient upstream cancellation when inbound request aborts before upstream response completes

Context

Symfony HttpClient executes upstream calls with its own timeout configuration (timeout, max_duration, stream timeout) that operates independently of the enclosing HTTP request lifecycle. When a client disconnects early—closing the browser tab, cancelling a fetch, or hitting a reverse-proxy timeout—the inbound Symfony request terminates, but the outbound HttpClient request continues until its own limits are reached.

Constraint

Applications running on Symfony 6.4 or 7.x with the default cURL transport need upstream calls to stop promptly when the outer request is aborted, avoiding worker saturation and connection-pool exhaustion. The framework does not automatically propagate the inbound cancellation to the HttpClient response by default.

Open questions

1. Which combination of HttpClient service options (timeout, max_duration, stream) and kernel event listeners (kernel.terminate, kernel.request connection status checks) reliably cancels the upstream call across both cURL and stream transports?
2. Does wrapping the HttpClient call in a Symfony\Contracts\HttpClient\HttpClientInterface with a custom Symfony\Component\HttpClient\Response\CancellableResponseInterface implementation provide deterministic cleanup without version-specific transport hacks?
3. Are there documented service-definition patterns in config/packages/http_client.yaml that guarantee cancellation propagation for Symfony 6.4 LTS and 7.x without requiring per-controller boilerplate?