Http Laravel Package

Technical Evaluation

Release delta (v4.0.2). A patch release that sets UrlEncodedParser as the parser for multipart/form-data. Two facts matter more than the change itself: (1) the package now visibly exposes a pluggable body-parser layer, an abstraction not described in the prior assessment; (2) the change was shipped as a patch despite altering runtime behavior for a content type. Neither shifts the strategic verdict, but both refine the risk picture and the verification plan.

Positioning. slick/http remains a framework-agnostic PSR-7 HTTP foundation — message objects, a middleware-driven request runner, session handling, body parsing, and an HTTP client. It is not a Laravel package and does not target Laravel's HTTP kernel: no service provider, no facade, no published config, no HttpFoundation bridge. The new parser registry confirms the design intent — this is a self-contained HTTP stack that owns the request lifecycle end to end, including how request bodies are interpreted. That is precisely the layer Laravel already owns.

Architecture fit. Laravel builds on Symfony HttpFoundation (Request/Response) with its own kernel, router, middleware pipeline, session manager, cookie encryption, and HTTP client. Slick/Http occupies the same layer of the stack rather than a layer above it.

On the parser change specifically. Routing multipart/form-data to a class named UrlEncodedParser is a semantic mismatch worth understanding before anything else. multipart/form-data (RFC 7578) is a boundary-delimited, per-part structure with its own content-type and disposition headers; application/x-www-form-urlencoded (RFC 1867/WHATWG URL) is a flat key=value&key=value string with percent-encoding. They are not interchangeable. Either the class name is a misnomer for a broader parser, or multipart bodies will be handled by logic written for a different encoding. The likely practical consequence is a silent failure mode: malformed or partially-parsed bodies rather than an exception, because lenient parsers rarely reject. This is a question to answer by reading the code, not by reading the changelog.

Integration feasibility. Unchanged: technically possible in narrow slices, not feasible as a foundation. No first-party Laravel path exists, and the parser layer adds surface area that overlaps native PHP behavior rather than complementing it.

Technical risk.

Key questions to resolve before any commitment.

1. New: What parses multipart/form-data in v4.0.2 — is UrlEncodedParser misnamed, or does multipart actually flow through URL-encoded logic? What happens to a multipart body with file parts?
2. New: Is the parser registry configurable, and can a parser be swapped per content type? Is parser selection strict (unknown content type → error) or lenient (→ empty body)?
3. New: Why was this a patch release rather than a minor? What is the project's stated compatibility policy for behavioral changes?
4. Is the middleware interface PSR-15 compliant, or Slick-specific?
5. Does the PSR-7 implementation pass the full php-http/psr7-integration-tests suite, including streams and uploads?
6. Maintainer count, commit cadence, issue-response history over 12 months, SECURITY.md presence.
7. How are sessions stored; are IDs regenerated on privilege change; are cookie payloads signed/encrypted?
8. Dependency currency and pinning (PSR-7 v1 vs v2, PHP 8.1–8.4), and a PSR-18/PSR-17 story for the client.

Integration Approach

Stack fit. Assume Laravel 10–12 on PHP 8.2+. There is no first-party path: no provider, no config publish, no container bindings. Any use is manual wiring inside a package or a narrow module. The v4.0.2 parser layer does not change this — it adds an abstraction that maps to nothing in Laravel, because Laravel inherits already-decoded request bodies from PHP and Symfony.

Migration path — three options, ranked. The release does not change the ranking.

• Option C (recommended): do not adopt. No migration. Keep symfony/psr-http-message-bridge + nyholm/psr7 for PSR-7 interop, Laravel's Http client, Laravel sessions. Zero risk, zero integration cost.
• Option B (conditional): bounded PSR-7 usage. Adopt only the message classes inside an isolated, framework-independent package where PSR-7 output is a hard requirement. Pin the version explicitly (recommend 4.0.2 exact rather than ^4.0, given the patch-level behavior change), and enforce a boundary so the types never leak into application code. Do not adopt the parser layer — it has no in-app use case.
• Option A (not recommended): foundational adoption. Replacing Laravel's kernel. Now includes owning request-body parsing semantics you would otherwise get free from PHP. Weeks of effort, unproven payoff against a 0-star dependency.

Compatibility. Unchanged materially: verify PHP bounds, PSR-7 v1 vs v2 return-type signatures, and interface collisions with already-installed Psr\Http\Message types. Two new items — confirm the parser registry does not depend on a specific PSR-7 stream implementation, and confirm behavior under Octane/Swoole, where php://input is readable once and a hand-rolled parser must not assume re-readable streams.

Sequencing (if Option B is pursued).

1. Day 1 — multipart spike (new, highest value). Construct a real multipart/form-data body with two text fields and a small file part, feed it to the v4.0.2 parser, and diff the parsed output against expectation. Also feed it a URL-encoded body and a JSON body to check strictness. This is now the cheapest test with the highest chance of ending the evaluation.
2. Week 1 — compliance spike. Clone, run php-http/psr7-integration-tests, record pass/fail per test.
3. Week 1 — security read. Review session code and cookie handling line by line; check ID regeneration and signing.
4. Week 2 — boundary prototype. Wire the messages into one package behind an adapter interface, then attempt a swap to nyholm/psr7 and measure the diff. A trivial swap means the dependency is doing nothing you can't get elsewhere.
5. Week 2 — decision gate. Adopt only if the multipart spike is clean, the conformance suite passes, and the adapter test shows a concrete, non-replicable benefit.
6. Ongoing — vendor isolation. Fork to an internal namespace and pin the commit if adopted, so abandonments and patch-level behavior changes are survivable.

Operational Impact

Maintenance. Still 0 stars and 0 dependents, so maintenance transfers almost entirely to your team. The v4.0.1 → v4.0.2 cadence is a genuine positive: the project ships. But the release also demonstrates that behavioral changes land in patch versions, which raises the ongoing cost of staying current — you cannot rely on the version constraint to protect you. Budget for diff review on every bump, plus forking and patching if adopted.

Support. Expect no community, documentation depth limited to source, and slow or absent issue responses. The changelog style (one line, no rationale) means the why behind behavioral changes is not documented — you will read code to answer questions the release notes should answer. Internal documentation of your integration is mandatory.

Scaling. For narrow PSR-7 DTO use, negligible. For kernel, session, or parser replacement, unmeasured: PSR-7 immutability allocates per header mutation, session scalability depends on the configured backend, and body parsing now adds a full-buffer read step whose memory profile on large uploads is unknown. Under Octane/Swoole, persistent workers amplify any static or request-scoped state bugs, and single-read input streams become a real constraint. None of this is benchmarkable without investment.

Failure modes.

Ramp-up. The API surface remains small: a senior PHP engineer is productive in one to two days, plus a half-day for the PSR-7 immutability model. The parser layer adds little learning cost but demands judgment — you must decide whether its multipart behavior is trustworthy, which requires reading the implementation rather than the docs. The dominant cost is still the absence of Laravel's scaffolding: routing, DI, auth, validation, error rendering, and testing helpers must be rebuilt or worked around if Option A is chosen.

Bottom line. Unchanged recommendation — Option C, no adoption — with Option B (isolated PSR-7 message usage, exact version pin) as the only defensible exception. The v4.0.2 release does not create a use case; it adds a low-fit component and one new verification item that should be run first, because a multipart parser routing through URL-encoded logic is the kind of defect that fails quietly in production.