Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Http Server Form Parser Laravel Package

amphp/http-server-form-parser

Parses application/x-www-form-urlencoded and multipart/form-data request bodies for amphp/http-server, giving handlers easy access to submitted form fields and uploaded files with a simple, asynchronous API.

Deep Wiki
Context7

Product Decisions This Supports

  • Stack correction first: despite the brief, this is not a Laravel package. It is a plugin for amphp/http-server (AMPHP's event-loop-based HTTP server, Revolt loop, PHP 8.1+). It is only actionable if a product decision has already been made — or is being made — to run services on AMPHP rather than PHP-FPM/Laravel/Symfony. Treat it as an input to that decision, not to a Laravel roadmap.
  • Build vs. buy on a narrow, error-prone problem: multipart/form-data parsing (boundary detection, part headers, streaming bodies, urlencoded payloads) is fiddly, easy to get subtly wrong, and rarely differentiating. Adopting an MIT-licensed parser avoids roughly 1–3 engineer-days plus ongoing edge-case maintenance.
  • Feature enablement for async services: webhook receivers, internal admin/tooling endpoints, file-upload ingestion, and API gateways that must accept application/x-www-form-urlencoded or multipart/form-data — specifically where the service already runs on amphp/http-server.
  • Architecture/roadmap gating: if the roadmap has no event-loop/async PHP services, this package should carry zero roadmap weight. If it does, this fills a required gap so that no team hand-rolls a parser as a side project.
  • Not a validation or upload-policy decision: it parses form data; it does not give you validation, CSRF, size/quota policy, malware scanning, or storage lifecycle. Those remain product/engineering decisions layered above it.

When to Consider This Package

Consider it when:

  • The service runs on amphp/http-server v2 (or an AMPHP-based framework such as DriftPHP) and receives real form submissions.
  • You need both multipart/form-data (including file parts) and application/x-www-form-urlencoded handled consistently.
  • You want to keep form handling streaming-friendly and inside the existing async request pipeline rather than bolting on a synchronous parser.
  • The blast radius of the dependency is small — i.e., it is wrapped behind an internal request-parsing adapter, so substitution is a contained change.

Look elsewhere when:

  • The product is Laravel or Symfony: use the framework's native request/form handling. This package adds nothing there.
  • You are on PHP-FPM/nginx and have no AMPHP server: no applicable surface.
  • You need a maintained, SLA-backed dependency: 18 stars, a single 2023-08-25 release, unknown repository, and no visible release cadence are real supply-chain signals. Vendor it, fork it, or budget a spike to confirm it works on your PHP/AMPHP versions before committing.
  • You need validation, CSRF, upload quotas, or storage policy — those are your layer, not this one.
  • You require active security response for a public-facing upload path; the low-maintenance profile argues for a thin internal wrapper plus a documented fallback.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free (MIT) utility that solves one narrow plumbing problem — reading submitted web forms — for services built on AMPHP's async HTTP server. It is not part of our Laravel stack and carries no strategic weight. The upside is a few engineering-days saved and fewer hand-rolled parsing bugs; the downside is a tiny, thinly maintained dependency. The decision is low-cost and fully reversible, so it should be approved only as a tactical, wrapped dependency inside an async service — never as a platform bet.

For engineering: It removes a well-known class of bugs (multipart boundaries, part headers, encoding differences) from any AMPHP service that accepts forms. Pin the version, wrap it behind an internal FormRequestParser interface, add contract tests against representative payloads (file parts, empty fields, large bodies), and keep a fallback path so the dependency can be swapped or vendored without touching handlers. Verify compatibility with your current amphp/http-server and PHP versions before adoption — the last release predates recent AMPHP majors in some cases.

Recommendation: Conditional adopt. Green-light only for teams already committed to amphp/http-server; otherwise take no action and revisit if/when an async PHP service enters the roadmap.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
frankyso/ipaymu
3mdikram/worldmoneywords
snowsoft/config
itmosoft/laravel-subscriptions
larva/laravel-ai-qwen
diephp/sequences
users-au/socialite-provider
twidpay/twid-logger
mrnewport/laravel-plaid
mrnewport/laravel-repo
mrnewport/laravel-docsign
mrnewport/laravel-stow
mrnewport/laravel-flow
mrnewport/laravel-priceable
mrnewport/laravel-nestedterms
fredmeng/laravel-apidoc-generator
itstructure/laravel-multilingual-tools
pdustdar/elasticsearch
markupai/php-sdk
rlacerda83/lumem-microservice-shipment