quantum-php / quantum-php/framework

Replace HttpClient php-curl-class transport with native curl adapters

Open
#565 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement http
Dominant language
PHP
Stars
36
Forks
22
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading the existing HttpClient adapter and factory refactor, including the HttpClientFactory entry points and existing HttpClient unit tests. Treat the single-request and multi/async adapters as separate child tickets; done means stable public APIs, validated request and callback behavior, and removal of php-curl-class only after both adapters pass parity checks.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
backend, networking
Issue type
Refactor
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.