- What does illuminatech/multipart-middleware actually do?
- It is a Laravel HTTP middleware that parses multipart/form-data request bodies sent with verbs other than POST, such as PUT and PATCH. PHP only natively populates $_POST and $_FILES for POST requests, so this middleware hydrates the Laravel request with regular input fields and uploaded files for those other verbs. In practice it lets you accept REST-style uploads like PUT /documents/{id} with an attached file without changing your controllers.
- How do I install illuminatech/multipart-middleware?
- Install it with Composer, for example composer require illuminatech/multipart-middleware. The package is a self-contained middleware and does not require publishing config or running migrations. After installing, register the middleware class in your HTTP kernel or on a specific route group.
- How do I register this middleware in Laravel?
- Add the middleware class to the $middleware or $middlewareGroups array in app/Http/Kernel.php for global use, or to $routeMiddleware and then attach it to individual routes and groups. The lowest-risk approach is to apply it only to the routes that actually receive non-POST multipart uploads, so existing POST flows keep their current behavior. It can be assigned per route group, which makes a gradual rollout straightforward.
- Which Laravel and PHP versions are supported?
- The supported version matrix is not documented in the package overview, so check composer.json in the repository for the required illuminate/http, symfony/http-foundation, and PHP constraints. The package is community-maintained rather than a first-party Laravel component, so its constraints are not guaranteed to track the latest framework releases. Confirm your target Laravel and PHP versions are covered by the package CI before adopting it, and re-check after every framework upgrade.
- Does it support file uploads on PUT and PATCH requests?
- Yes, that is its primary purpose. It parses the multipart body of PUT, PATCH, and other non-POST requests and populates the request with the uploaded files and normal input fields. That means code that normally reads $request->file('document') works on a PUT route without a workaround.
- Will $request->file(), $request->input(), and FormRequest validation work unchanged?
- That depends on whether the middleware's request wrapper fully satisfies the Illuminate\Http\Request contract, including file bag, input, query, and header access. Because it wraps the request, you should verify in a small proof of concept that $request->file(), $request->input(), validated() data, and FormRequest rules all behave identically to a normal POST upload. Test file rules such as mimes, max, and dimensions explicitly, since those rely on Symfony's UploadedFile behavior.
- Does it buffer uploads in memory or stream them to disk?
- The overview does not state how the parser handles large bodies, so treat this as something to verify before production use. Multipart parsing can buffer the whole body in memory, which becomes a real problem with large files and concurrent uploads, so load-test with realistic file sizes and watch memory usage. Also confirm how it interacts with PHP's post_max_size and upload_max_filesize limits and what happens when a body exceeds your configured maximum.
- Where should the middleware sit in the Laravel middleware stack?
- Place it early enough to hydrate the request before it reaches your controller, but after any size or security guards you rely on. Middleware that wraps or replaces the request, such as signature validation or custom request-wrapping middleware, can interact unexpectedly with a request wrapper, so audit the ordering. Also check behavior alongside TrimStrings and ConvertEmptyStringsToNull, since those operate on input that this middleware populates.
- Is it safe to use in production given the small number of stars?
- It has around 33 GitHub stars and is maintained by a single author, which means limited community scrutiny and no documented security response process. Multipart parsing involves boundary handling, malformed input rejection, and size limits, so fuzz and load-test it against your real traffic profile rather than assuming it is battle-tested. Pin the version in composer.lock, review the source, and have a fallback path in case the package stops receiving updates.
- What is the license, and are there alternatives?
- Composer reports the license as NOASSERTION, so procurement or legal should confirm the actual license text in the repository before you ship it. If that is a blocker, alternatives include sending uploads as POST with Laravel's _method spoofing, or writing a small custom parser for the specific routes that need PUT or PATCH uploads. Both avoid the third-party dependency, at the cost of an extra convention or some custom code.