Http Bundle Laravel Package

Getting Started

1. Re-check composer installability — the premise has changed. v1.1.4 is a patch release that explicitly targets "newer Symfony versions" (deprecation fixes) and adds "forward compatibility with Symfony4". That is not the same as active maintenance — it is a deprecation sweep plus a Symfony 4 compat pass, not a Symfony 5/6 port. Try composer require iltar/http-bundle:^1.1 on a scratch branch. On Symfony 4.x this likely resolves now; on Symfony 5+ expect the same symfony/http-kernel conflict as the previous assessment, because the "forward compatibility" stops at 4. The path/VCS-with-widened-constraints fallback still stands.
2. Register the bundle. Unchanged: config/bundles.php on Flex, AppKernel::registerBundles() on legacy. The vendor/package mismatch (Composer iltar/http-bundle vs repo linaori) is still real; config root key still comes from the bundle's getContainerExtension() alias, not the package name.
3. Where to look first, in this order:
   • README.md — still the only authoritative statement of intended behavior.
   • The 1.1.3 → 1.1.4 diff — new and worth doing first. The release notes are deliberately vague ("some deprecation notices"), so the diff is the only precise map of which event classes, container APIs, and deprecations were touched. It tells you where the remaining Symfony 5+ landmines are.
   • src/DependencyInjection/Configuration.php + Extension.php — still the real API surface.
   • src/Resources/config/*.xml|yaml — still where priorities and tags live.
   • src/EventListener/ and src/EventSubscriber/ — still where the request-cycle behavior lives.
4. First use case: install, register, then run bin/console config:dump-reference <alias> and bin/console debug:event-dispatcher kernel.request. Enable exactly one toggle from the config tree, hit a route, confirm behavior in the profiler. On a Symfony 4.x target, additionally run the suite with SYMFONY_DEPRECATIONS_HELPER=max[direct]=0 — that tells you whether the patch actually closed the deprecation surface or just reduced it.

Implementation Patterns

• Config-first, not code-first. Bundles of this vintage expose behavior as boolean/scalar flags. Enable features in config/packages/<alias>.yaml rather than wiring services by hand; you get the bundle's own defaults and priorities for free.
• Treat each listener as a middleware. Map the subscribers to Laravel middleware mentally: kernel.request ≈ global middleware before routing, kernel.response ≈ response-transform middleware, kernel.exception ≈ app/Exceptions/Handler. If you are porting a behavior into Laravel, port it at that layer, not as a controller concern.
• Override via decoration, never by editing vendor. Use decorates: <service_id> in your own services.yaml, or register a competing subscriber with a higher priority on the kernel.event_subscriber tag. Read the bundle's priorities in its service definitions before picking a number.
• Keep it behind a feature flag in your own config. Wrap the bundle's config in your app's parameters/env so you can disable it per environment. One patch release does not make an archived-era bundle load-bearing; keep the kill switch.
• Pin to ^1.1 and treat 1.1.4 as the modern baseline. The forward-compat work landed as a patch, so it is non-breaking. Anything below 1.1.4 is pre-forward-compat and not worth starting a new integration on.
• Test through the kernel, not the listener. Use Symfony's WebTestCase / KernelBrowser and assert on the response. These listeners only make sense in a full request cycle; unit-testing a subscriber in isolation misses ordering effects — and, post-1.1.4, misses which deprecation path the patched code takes.

Gotchas and Tips

• The "archived, one release" framing in the previous assessment is now wrong. v1.1.4 exists, which disproves "one release since 2017". But one patch that fixes deprecations is not a maintenance commitment — check commit cadence and issue responsiveness before treating the repo as supported. The "treat this as reference code, not a dependency" guidance is softer now, not gone. Keep budgeting for taking ownership of the source.
• Symfony version drift — partially, not fully, addressed. The headline of 1.1.4 is exactly this: "fixes some deprecation notices thrown by newer Symfony versions" and "forward compatibility with Symfony4". Expect FilterResponseEvent-era renames and ContainerAwareInterface to be papered over for Symfony 4.x. They are not addressed for Symfony 5/6 — the 5.0 removal of ContainerAwareInterface and the FilterResponseEvent → ResponseEvent renames are still on you. The upgrade path is now "works on 4, fork to go further", not "fork from 2017".
• "Some" deprecation notices means some. Run SYMFONY_DEPrecATIONS_HELPER=max[direct]=0 (or max[total]=0 on stricter CI) with E_ALL in a test env, exercise the bundle's listeners through the kernel, and read the list. Anything the patch missed will surface there — that is a cheap check that tells you whether you're on a clean Symfony 4 baseline or still patching by hand.
• PHP 8 deprecations. Better shape than before because 1.1.4 sweeps deprecations, but "newer Symfony" in 2017/2018-era release notes normally means Symfony 3.4/4.x-era deprecations, not PHP 8.x. Dynamic properties, curly-brace string offsets, and each()-adjacent idioms from that era can still fatal. Run on your target PHP before committing.
• Debugging tools: debug:event-dispatcher (with --dispatcher=event_dispatcher) shows listener order and priorities; debug:container --tag=kernel.event_subscriber lists everything tagged; cache:clear after any config change, since the container is compiled.
• Config isn't validated the way you expect. 2017-era Configuration.php files often omit ->cannotBeEmpty() / enum validation, and 1.1.4 was a deprecation/compat pass, not a config-tree rewrite — a typo silently falls back to a default. Grep the config tree for the key you set and confirm the default differs from what you passed.
• Extension points worth knowing: compiler passes (to reorder listeners wholesale), HttpKernelInterface decoration (to wrap the whole cycle), and the kernel.event_subscriber tag's priority attribute (the surgical option). Prefer the tag priority — it is the least invasive and survives a fork cleanly, which still matters here because 1.1.4 is a patch, not a promise of future patches.