Summary
Follow up the HttpClient adapter/factory refactor by replacing the php-curl-class/php-curl-class transport behind Quantum-owned adapters with native curl implementations, while preserving the public HttpClient facade, factory methods, helpers, and adapter contracts introduced in the previous work.
This is an umbrella ticket. The implementation should be split into adapter-specific child tickets so the simpler single-request adapter can be validated separately from the higher-risk multi-request behavior.
Goals
- Keep the public
HttpClient API stable.
- Keep
HttpClientFactory and helper APIs stable:
HttpClientFactory::createRequest() / httpRequest()
HttpClientFactory::createMultiRequest() / httpMultiRequest()
HttpClientFactory::createAsyncMultiRequest() / httpAsyncMultiRequest()
- Replace vendor-backed internals adapter by adapter.
- Remove
php-curl-class/php-curl-class only after both native adapters have acceptable parity.
- Avoid leaking raw native curl handles through the public facade.
Child Tickets
- Native
CurlAdapter implementation for single requests.
- Native
MultiCurlAdapter implementation for multi and async requests.
Acceptance Criteria
- Child tickets are completed and validated independently.
- Existing HttpClient unit tests continue to pass.
- Downstream single-request usage such as remote image downloads continues to work.
- Multi-request callback behavior is covered before removing the dependency.
php-curl-class/php-curl-class is removed from Composer only after native single and multi adapters are both complete, reviewed, and validated.
Notes
The multi-curl adapter is the risky part because queueing, callbacks, request IDs, headers, cookies, options, errors, and response aggregation all need behavior parity. Do not treat dependency removal as complete after only the single-request adapter is native.
Summary
Follow up the HttpClient adapter/factory refactor by replacing the
php-curl-class/php-curl-classtransport behind Quantum-owned adapters with native curl implementations, while preserving the publicHttpClientfacade, factory methods, helpers, and adapter contracts introduced in the previous work.This is an umbrella ticket. The implementation should be split into adapter-specific child tickets so the simpler single-request adapter can be validated separately from the higher-risk multi-request behavior.
Goals
HttpClientAPI stable.HttpClientFactoryand helper APIs stable:HttpClientFactory::createRequest()/httpRequest()HttpClientFactory::createMultiRequest()/httpMultiRequest()HttpClientFactory::createAsyncMultiRequest()/httpAsyncMultiRequest()php-curl-class/php-curl-classonly after both native adapters have acceptable parity.Child Tickets
CurlAdapterimplementation for single requests.MultiCurlAdapterimplementation for multi and async requests.Acceptance Criteria
php-curl-class/php-curl-classis removed from Composer only after native single and multi adapters are both complete, reviewed, and validated.Notes
The multi-curl adapter is the risky part because queueing, callbacks, request IDs, headers, cookies, options, errors, and response aggregation all need behavior parity. Do not treat dependency removal as complete after only the single-request adapter is native.