Httpmessage Laravel Package

Product Decisions This Supports

• Roadmap / interoperability scope: whether our Laravel service needs to speak PSR-7 at all — e.g., to consume PSR-15 middleware, integrate a third-party SDK that type-hints Psr\Http\Message\RequestInterface, or hand a request to an OAuth2 server implementation. This is an enabler decision, not a feature decision; no end user will ever see it.
• Build vs. buy (the real one): "PSR-7 implementation" is a commodity. The decision this package informs is which implementation we standardize on, not whether to write one. Building is never justified — PSR-7 has been frozen since 2015 and every implementation is a thin, well-understood wrapper over streams and URI parsing.
• Dependency portfolio / tech-debt triage: with 0 dependents and no release since January 2018, adopting this is a supply-chain and maintenance-liability decision. A PM should treat it as "do we want an unmaintained transitive dependency in our lockfile?" — answer: no, unless there's a hard constraint.
• Concrete use cases it could unblock: converting Illuminate\Http\Request into a PSR-7 message before handing it to a PSR-7-only library; unit-testing HTTP message objects without booting the framework; streaming large uploads/responses; abstracting HTTP clients behind PSR-18.
• What it should not drive: positioning, pricing, or customer-facing commitments. PSR-7 is invisible plumbing; it can unblock a roadmap item but can never justify one.

When to Consider This Package

Adopt only if all of the following hold — which, realistically, they don't:

• You need a PSR-7 implementation (you probably don't; Laravel's own Illuminate\Http covers 90% of cases, and Laravel's HTTP client already drags in guzzlehttp/psr7 transitively).
• You have an explicit constraint (license, air-gapped vendor review, existing internal fork) that rules out maintained alternatives.
• You accept an unmaintained, PHP 7.0-era codebase with no security response process and untested PHP 8.2+ behavior.

Look elsewhere by default. The category is well served:

• nyholm/psr7 — lightweight, actively maintained, the de-facto modern choice; pair with symfony/psr-http-message-bridge for Laravel↔PSR-7 conversion.
• guzzlehttp/psr7 — likely already installed; zero incremental cost in most Laravel apps.
• laminas/laminas-diactoros — heavier, enterprise-supported.

Also note this package ships only the PSR-7 interfaces implementation — it does not include the Symfony bridge or Laravel service provider you'd need to actually wire it into a Laravel app. So even in the best case you're writing integration glue for an abandoned library.

The high opportunity score (7.21) reflects the category (PSR-7 interop is broadly useful), not this vendor. That opportunity is already captured by maintained incumbents.

How to Pitch It (Stakeholders)

To executives: We evaluated kambo/httpmessage as a PSR-7 implementation for Laravel. Recommendation: do not adopt. It's functional in principle but effectively abandoned — last release January 2018, zero dependent packages, single maintainer, no security process. The underlying need (interoperating with PSR-7-based libraries) is real but narrow and fully covered by maintained, free alternatives we can adopt in one line of Composer config. Approving this would add maintenance and supply-chain risk for zero product benefit. No action required beyond recording the decision.

To engineering: 5 GitHub stars, 0 dependents, no commits in ~7 years, no declared PHP 8 support. Cost to adopt is low in code and high in risk — we'd own an unmaintained fork the first time a PHP upgrade or security scan flags it, and we'd still have to write the Laravel↔PSR-7 bridge ourselves. If we need PSR-7, standardize on nyholm/psr7 + symfony/psr-http-message-bridge, or just rely on the guzzlehttp/psr7 we already ship. If someone has a specific reason this package wins, bring it to the architecture review with the constraint spelled out; absent that, we close this as "evaluated, declined."