Psr7 Laravel Package

Technical Evaluation

Architecture fit

• PSR-7 describes HTTP messages; workerman/psr7 is one concrete implementation of psr/http-message. A Laravel application only touches PSR-7 at its edges — async HTTP clients, websocket/SSE adapters, or bridges to symfony/psr-http-message-bridge. Laravel's core request/response lifecycle is Symfony HttpFoundation, not PSR-7, so this package has no path into the framework itself.
• In practice this arrives transitively: workerman/http-client (and the wider Workerman/webman ecosystem) pulls it in. It is plumbing, not a product decision. The 10-star count and single-digit opportunity score reflect that — nobody adopts this on merit; they inherit it.
• The concrete classes (Request, Response, Stream, Uri) are internal to that ecosystem. If our code type-hints against them rather than Psr\Http\Message\*Interface, we've coupled to a library the maintainer can replace at will.

Integration feasibility

• Low effort, low value. composer require is trivial; the work is deciding whether we want a second PSR-7 implementation coexisting with guzzlehttp/psr7 (already present wherever Guzzle/Laravel's HTTP client is used). Two implementations are spec-compatible but instanceof-incompatible — a classic source of silent adapter bugs.
• Note the naming mismatch: repo is walkor/psr7, Packagist package is workerman/psr7. Version constraints, security advisories, and GitHub watchlists all split across two identifiers. That's a supply-chain visibility gap, not a blocker.

Technical risk

• Maintainer concentration: single primary author (walkor), no corporate backing, no commercial support tier.
• Fork drift: widely understood to be derived from nyholm/psr7 (one of the fastest, best-maintained implementations). If it is a hard fork without an upstream-merge policy, PSR-7 spec updates, header-casing fixes, and CVEs land upstream and stop there. This needs verification — ask directly.
• Low blast radius, high subtlety: it's a thin allocation layer, so a bug rarely crashes loudly; it manifests as header normalization, chunked/streamed body, or URI-escaping defects that are expensive to trace through a queue worker.
• Release cadence: a March 2025 release is fine, but there's no published support window or deprecation policy.

Key questions

1. Is this a hard fork of nyholm/psr7? Is there a documented upstream-merge or patch-porting process?
2. Which constraint does workerman/http-client pin, and does it accept PSR-7 v2 (psr/http-message: ^1.0 || ^2.0) with the v2 return types?
3. Does it ship PSR-17 factories (psr/http-factory)? Without them, interoperability with Laravel/Symfony tooling requires hand-written factories.
4. Is there a published security contact and advisory feed on the walkor vendor name?
5. Does it honor PSR-7 immutability rigorously (messages immutable, streams mutable) — or does it alias streams for performance, as some Workerman forks do?
6. Do we require it directly anywhere, or is it purely transitive? (composer why workerman/psr7)

Integration Approach

Stack fit

• Adopt only if we are deliberately introducing Workerman into a Laravel deployment — e.g. replacing blocking Guzzle fan-out with workerman/http-client for high-concurrency outbound calls. In that case it comes along and should be accepted, pinned, and isolated.
• Otherwise: don't. For general PSR-7 needs use nyholm/psr7 (lightweight, actively maintained, upstream of this) or guzzlehttp/psr7 (already in the tree, zero marginal risk).

Migration path

• There is no meaningful "migration to" story — the package is a leaf dependency. The real decision is containment: keep PSR-7 usage behind our own interface so the concrete implementation is swappable in one commit.
• If already present, treat removal as a non-goal. Replacing it means also replacing whatever Workerman component pulled it in; the cost is in the runtime, not the library.

Compatibility

• Verify PHP floor against our fleet (Workerman 5.x requires PHP 8.1+, which likely forces the constraint anyway).
• Coexistence with guzzlehttp/psr7 is legal but requires discipline: never let concrete classes cross a boundary. Convert at the edges via symfony/psr-http-message-bridge or explicit factories.
• Streaming bodies from async clients must be drained and closed explicitly; PSR-7's mutable-stream carve-out makes "message is just data" assumptions unsafe.

Sequencing

1. composer why / composer depends to establish whether it's transitive — resolve ambiguity before any design discussion.
2. Read the fork's README + diff against nyholm/psr7; file the upstream-merge question with the maintainer.
3. Add an ADR recording: pinned version, rationale, the adapter boundary, and the exit trigger (e.g. "if upstream diverges beyond N commits, swap to nyholm/psr7").
4. Introduce the adapter/PSR-17 factory layer before any feature code touches PSR-7 types.
5. Only then wire up the Workerman async path, behind a feature flag, with a Guzzle fallback.

Operational Impact

Maintenance

• Effectively a one-person project with a small surface area and low release velocity. That's acceptable for glue code and unacceptable for anything security-adjacent — and HTTP message parsing sits closer to that line than most glue.
• MIT license means the worst case is a fork we maintain ourselves. Budget that as a real, if unlikely, contingency: the codebase is small enough that a mid-level engineer could own it.

Support

• Community channels (Workerman GitHub issues, Gitter/QQ groups); no SLA, no vendor to escalate to. Timezone and language skew should be expected. Any incident response plan must assume self-sufficiency.

Scaling

• The library itself is a negligible cost — thin object wrappers, allocation-bound, comparable to nyholm/psr7 on throughput. Scaling risk lives entirely in the Workerman runtime (event loop, worker counts, memory retention across coroutines), not here.
• Watch for unbounded memory growth from un-drained streams in long-lived workers; that is the realistic "scaling" failure and it presents as an OOM hours in, not at load time.

Failure modes

• Two-implementation confusion — instanceof and type-hint mismatches against guzzlehttp/psr7 surfaces as confusing runtime errors at integration points.
• PSR-7 v1/v2 skew — a v2-only return type against a v1-expecting consumer produces fatals that only appear when two dependency paths meet in one process.
• Fork divergence — a spec or security fix lands upstream, not here; discoverable only by reading nyholm/psr7 release notes, which nobody does.
• Immutability violations — aliased streams cause cross-request contamination in long-running workers; the hardest class of bug to reproduce.
• Vendor-name mismatch — advisories filed against walkor/psr7 won't page anyone watching workerman/psr7.

Ramp-up

• Near zero to use; meaningful to own. The learning cost is PSR-7's mental model — immutability, stream semantics, factory patterns — not this package. Engineers coming from Laravel's Request/Response will instinctively mutate; that instinct is the source of most defects here.
• Recommend a short internal note on the adapter boundary and a lint rule or static-analysis check forbidding Walker\Psr7\* (or equivalent concrete namespace) outside the adapter package.

Bottom line for the roadmap: do not plan around this package. Accept it as a pinned transitive dependency if Workerman async HTTP is on the roadmap, contain it behind interfaces, and treat nyholm/psr7 as the designed exit. If Workerman is not on the roadmap, this never enters the picture.