- What does iltar/http-bundle actually do?
- It is a Symfony bundle that provides status-code-specific HTTP exception classes and a listener that converts those exceptions into proper HTTP responses. The goal is consistent, meaningful error output from controllers and APIs without repeating try/catch or response-building code. It is built around Symfony's HttpKernel: a Bundle subclass, a DI extension, and event subscribers on kernel.request and kernel.response.
- Is iltar/http-bundle compatible with Laravel?
- No, not as a package. It is a Symfony bundle, and Laravel has no bundle system; package discovery looks for an Illuminate\Support\ServiceProvider instead. Laravel also never dispatches the kernel.request and kernel.response events its listeners subscribe to. The only genuine overlap is symfony/http-foundation, which ships transitively in every Laravel app because Illuminate\Http\Request extends Symfony's Request.
- Will composer require iltar/http-bundle work in a Laravel application?
- Most likely not. The package has 2017-era dependency constraints and Laravel 10/11 will pin a much newer symfony/http-foundation, so Composer will probably refuse to resolve it. Even if installation succeeded, the bundle would register nothing and change no behavior. Confirm the resolution failure early, because that outcome alone settles the question.
- Is iltar/http-bundle still maintained and safe for production?
- The last release was November 2017, the repository is archived, and it has 39 stars with zero dependents. There is no CI, no security response process, and bus factor is one. PHP 8.x compatibility is unverified, and HttpFoundation signatures and deprecations have changed considerably between Symfony 3.x and current versions. Shipping it in the request path would be a real risk.
- Can I reuse any part of iltar/http-bundle in Laravel?
- Only classes that depend purely on symfony/http-foundation primitives are portable, and that is a source-extraction exercise rather than an integration. Inventory the public API, then sort each class into portable, non-portable, or obsolete. Move the portable ones into app/Support/Http or a small internal Composer package, keeping the MIT notice and attribution, and reimplement the rest idiomatically.
- How do I translate the bundle's Symfony kernel listeners into Laravel?
- A kernel.request or kernel.response listener becomes Laravel middleware or a service provider registration. Handle the request in middleware, catch or render your exception there, and return a response through Laravel's normal pipeline. Feature-test through the Laravel HTTP kernel with real routes and real requests rather than unit-testing listener classes in isolation.
- What are the alternatives to installing iltar/http-bundle?
- First check whether the behavior you want already exists natively in Laravel or Symfony, since method override handling, content negotiation, trusted proxies, and JSON exception rendering are now built in. If not, write a small middleware or exception renderer rather than depending on an archived bundle. Forking or path-repo replacing the package is an option, but it creates a permanent maintenance obligation that someone must own.
- How do I decide between forking iltar/http-bundle and reimplementing it?
- Run a one-to-two day spike to confirm whether the desired behavior already exists natively in your Laravel version. If it does not, reimplementing as middleware is usually cheaper than owning a fork of Symfony 3.x-era code. Fork only if a specific, well-tested class carries logic you cannot reasonably rewrite, and assign an explicit long-term owner before merging anything.
- Which Symfony version does iltar/http-bundle target, and does it run on PHP 8?
- It targets Symfony 3.x-era conventions and its composer.json predates modern PHP constraints. Running it on PHP 8.2 or 8.3 is unverified and likely to produce deprecation noise from dynamic properties and signature changes. Do not inherit its constraints; if you extract code, pin against the symfony/http-foundation version that ships with your Laravel release.
- How should I test HTTP exception handling before shipping it in Laravel?
- Write feature tests that hit real routes through the Laravel HTTP kernel and assert on status codes, headers, and response bodies. Cover the error paths your controllers and API endpoints actually expose, including validation failures and unexpected exceptions. If you extract classes from the bundle, add tests around the extracted code directly and audit any header or proxy handling for security impact before it reaches the request path.