Httpmessage Laravel Package

Technical Evaluation

What this package is. kambo/httpmessage is a standalone implementation of PSR-7 (psr/http-message), the FIG standard defining immutable value objects for HTTP requests, responses, URIs, streams, and uploaded files. It is a library, not a framework extension: no service provider, no facade, no config. In a Laravel codebase it can only ever occupy the HTTP boundary — it does not replace Illuminate\Http\Request/Response or Symfony HttpFoundation, which is what the framework's routing, validation, session, and middleware stack actually operate on.

Architecture fit: narrow and optional. Laravel is not a PSR-7 application. PSR-7 enters a Laravel codebase through exactly four doors:

The critical architectural point: PSR-7 consumers are typed against interfaces, so implementations are interchangeable by design. That makes this a commodity dependency with zero differentiation — the only selection criteria are conformance, maintenance, and compatibility. On all three, this package is weak.

Integration feasibility: mechanically trivial, compatibility-gated. composer require kambo/httpmessage and it works, if and only if its declared psr/http-message constraint resolves against what the rest of the tree wants. That is the whole risk surface, and it is a real one.

Technical risk (ranked):

1. psr/http-message 2.0 incompatibility — high likelihood, blocking. PSR-7 v1.x (2015) had no return types; v2.0 (2023) added them, and implementations must match exactly or PHP throws a fatal signature error. A package last released 2018-01-24 almost certainly pins ^1.0 only. Modern consumers (guzzlehttp/psr7 2.x, nyholm/psr7 1.x, most PSR-18 clients) require ^1.1 || ^2.0 or ^2.0, so Composer will either refuse to install or pin your entire HTTP layer to v1. Under PHP 8.x, if the resolver does allow a mix, you get a class-loading fatal. This is the single question that decides the evaluation.
2. No PSR-17 factory support. PSR-17 (http-factory, 2018–2019) is how modern code creates PSR-7 objects without hard-coding a concrete class, and it's what symfony/psr-http-message-bridge and PSR-18 clients consume. A 2018 implementation predates or predates-final of this; expect to write and maintain your own factory adapter — which erodes the entire reason to use a batteries-free package.
3. Abandonment / supply chain. Last release 7+ years ago, 5 stars, 0 dependents, MIT, effectively single-maintainer. No security response path, no CVE monitoring, no PHP 8.x CI evidence. Composer audit tooling will surface it as an unmaintained transitive dependency in every future security review — a recurring tax.
4. Correctness surface is deceptively large. PSR-7 impls are mostly small, but they own URI parsing, header normalization/validation, stream wrappers, and multipart handling — exactly where subtle bugs (header injection via CRLF, URI edge cases, memory blowups from unbounded streams) live. Low-adoption code has not been adversarially exercised. Zero dependents means zero external bug pressure.
5. Ecosystem signal agrees. The composite score of 0.155 with a high opportunity (7.21) reads as "genuine gap, no viable incumbent adoption" — which describes the category's maturity, not this package's quality.

Key questions to resolve before any code is written:

1. What is the exact psr/http-message constraint in composer.json, and does it resolve alongside our current guzzlehttp/psr7 / HTTP client versions on our target PHP (8.2/8.3)?
2. Does the package declare php constraints and pass its own test suite on PHP 8.x? Is there a phpunit.xml and CI config at all?
3. Do we actually have a PSR-7 consumer, or is this a solution in search of a problem? Name the specific package or middleware requiring it.
4. If PSR-17 is unimplemented, who owns the factory adapter and its tests?
5. Is there a maintained alternative that clears the same requirement (nyholm/psr7 or guzzlehttp/psr7 — both already likely present transitively)?
6. Who is the accountable owner if a conformance bug surfaces in 18 months with no upstream to patch it?

Integration Approach

Stack fit. Poor-to-conditional. Laravel's request lifecycle never touches PSR-7; adding this package inserts a translation layer (HttpFoundation → PSR-7 → PSR-15 → back) that buys nothing unless a concrete downstream dependency demands it. Recommended default: do not adopt; use nyholm/psr7 (minimal, actively maintained, PSR-17 factories included) plus symfony/psr-http-message-bridge if a bridge is genuinely needed. Both are already in most Laravel dependency trees, so the marginal cost is ~zero and the risk delta is large.

If adoption is mandated (e.g. licensing, an internal standard, or an air-gapped constraint), the migration path is:

• Contain it. Never let Kambo\HttpMessage\* concrete classes appear in application or domain code. Type-hint only Psr\Http\Message\* interfaces, and resolve instances through an internal HttpMessageFactory interface we own. Swapping implementations then becomes a one-file change plus a container binding — hours, not weeks.
• Pin and lock. Exact version constraint ("kambo/httpmessage": "x.y.z"), committed composer.lock, and a conflict entry if it forces psr/http-message below what other dependencies need.
• Fill the gaps ourselves. Assume we must author: a PSR-17 factory set, a PHP 8 signature shim if the interfaces are v1-only, and a conversion adapter to/from HttpFoundation. Budget ~3–5 engineer-days for the adapter + tests, plus ongoing ownership.

Compatibility matrix to validate in a spike (≤1 day):

Sequencing:

1. Spike (1 day): answer key questions 1–3. If the psr/http-message constraint is ^1.0-only and our tree needs ^2.0, the evaluation ends here — no further work is justified.
2. Justification gate: a named consumer must be documented. "It might be useful later" is not a gate pass.
3. Contained pilot: factory interface + adapter, behind a feature flag, exercised by one integration path in a non-production environment.
4. Conformance + security review: run the PSR-7 integration test suite, run composer audit, document the unmaintained dependency in the risk register with a named owner.
5. Bounded rollout or exit. Define the exit trigger in advance: any PSR-7 conformance bug, any PHP minor version that breaks class loading, or any transitive dependency collision → rip-and-replace with nyholm/psr7, which the internal factory interface makes cheap.

Operational Impact

Maintenance: the dominant cost, and it is ours. An unmaintained dependency doesn't mean "no maintenance" — it means we are the maintainer, without the upstream's tests or intent. Realistic ongoing load: security-review exceptions every audit cycle, a manual patch path (composer patch/fork) if a bug lands, and periodic re-validation whenever PHP or psr/http-message moves. Compare against a maintained alternative where this load is near-zero. This is the clearest TPM-level argument against adoption: it converts a solved, commoditized problem into a bespoke ownership liability for no functional gain.

Support. No upstream issue response, no CVE feed participation, no vendor to escalate to. Internal engineers will not find this package in their prior experience; every question routes to whoever owns the adapter. If that person leaves, the knowledge leaves.

Scaling. Performance is not the concern — PSR-7 objects are lightweight and this implementation is unlikely to be a bottleneck versus Laravel's own request handling. The concern is scaling the team: each new engineer must learn a bespoke, undocumented HTTP message layer that exists nowhere else in their career. Onboarding cost is real and recurring; it does not amortize the way a well-known package does.

Failure modes (and blast radius):

The deadlock row is the one that bites teams months later: a single low-value package can veto an entire ecosystem upgrade, converting a decision made today into a blocker owned by someone who never saw the original justification.

Ramp-up. Low to install, moderate to operate correctly. Any engineer can call composer require. Operating it safely requires understanding PSR-7 immutability semantics (every with* returns a clone — a common source of silent no-op bugs), stream pointer/rewind behavior, and the HttpFoundation bridge's lossy spots (cookies, uploaded file metadata, non-rewindable body streams). Budget a short internal note documenting the factory contract and the immutability gotcha; without it, expect subtle bugs where a mutated request is silently discarded.

Recommendation. Do not adopt for a Laravel codebase on current PHP. The category is fully commoditized, two actively maintained implementations are already in most dependency trees, and this package's release date puts it on the wrong side of the psr/http-message 2.0 split — the single most expensive compatibility break to inherit. If a PSR-7 boundary is genuinely required, nyholm/psr7 + symfony/psr-http-message-bridge delivers the same interface-level fit with none of the ownership burden. If adoption is nonetheless mandated, contain it behind an internal factory interface from day one and write the exit trigger into the decision record before the first commit.