Cache Control Bundle Laravel Package

Technical Evaluation

Architecture fit: Effectively zero for a Laravel codebase. liip/cache-control-bundle is a Symfony bundle, not a framework-agnostic PHP library — it ships a LiipCacheControlBundle class extending Symfony's Bundle, depends on the Symfony DI container, event dispatcher, and HTTP kernel event system, and configures itself through Symfony's semantic configuration tree. Laravel's service container, middleware pipeline, and HTTP kernel are structurally incompatible; there is no bridge, no adapter, and no community evidence of one (0 dependents). The package's actual domain — HTTP cache-control header manipulation, ESI/SSI tag handling, and cache invalidation hints — is real and relevant to Laravel, but the implementation is bound to a runtime we do not use.

Integration feasibility: Not feasible without a port, and a port is not justified. The last release was December 2013, the repository is archived, and the upstream author explicitly directs users to FOSHttpCacheBundle. Any integration work would be (a) reimplementing the bundle's logic against Laravel's middleware and event system, or (b) pulling in friendsofsymfony/http-cache (the framework-agnostic core library underneath FOSHttpCacheBundle) and writing our own Laravel bindings. Option (b) is the only technically defensible path, and at that point the bundle under evaluation contributes nothing to the decision — we would be evaluating fos/http-cache instead.

Technical risk: Severe and non-mitigable. A 2013-vintage Symfony bundle targets Symfony 2.x APIs (Symfony\Component\HttpKernel\Event\FilterResponseEvent, the old getRequest()/setResponse() signatures on kernel events, Symfony\Component\DependencyInjection\Configuration patterns). Those classes were renamed and their contracts changed in Symfony 4.3+ and removed in Symfony 5. On any modern PHP runtime (8.1+) the bundle will not autoload cleanly, let alone boot. There are no security advisories because there is no maintenance — the risk is not a known CVE but unbounded unknown behavior in an unmaintained dependency. Supply-chain exposure is limited only by the fact that we would never install it.

Key questions:

1. What cache-control requirement is driving this evaluation — response header policy, ESI/SSI fragment assembly, or tag-based invalidation? Each has a different (and much better) answer in the Laravel ecosystem.
2. Is there a legacy Symfony service in the estate that this bundle is meant to interoperate with? If so, the question is about that service's upgrade path, not about adopting this bundle.
3. Who is the accountable owner for a package that has been archived for over a decade, and what is the exit plan if it breaks?
4. Has spatie/laravel-responsecache, fos/http-cache with custom Laravel bindings, or plain response middleware been assessed and rejected? If not, this evaluation is premature.

Integration Approach

Stack fit: Poor. The package assumes a Symfony 2.x kernel, DI container, and config component. Laravel's middleware, Illuminate\Http\Response header bag, and service provider registration model map onto the same concepts but not the same contracts. Bridging them would mean maintaining a compatibility shim whose surface area exceeds the functionality being gained.

Migration path: There is no migration to this package; there is only a migration away from it. The README's own guidance is the correct path: for Symfony shops, move to FOSHttpCacheBundle, which is actively maintained and supports current Symfony versions. For a Laravel codebase, the equivalent decision is:

• Header policy only: native middleware setting Cache-Control, ETag, Vary, and Surrogate-Control on responses. No dependency required.
• Full-page response caching: spatie/laravel-responsecache, which is Laravel-native, actively maintained, and integrates with the framework's cache stores and middleware groups.
• Surrogate/CDN cache invalidation and ESI: friendsofsymfony/http-cache as the framework-agnostic core, wrapped in a thin in-house service provider — only if tag-based invalidation against a specific reverse proxy (Varnish, Fastly, Cloudflare) is a genuine requirement.

Compatibility: The bundle's constraints (Symfony 2.x, PHP 5.3–5.5 era) are incompatible with any supported Laravel release. Laravel 10/11 require PHP 8.1+; the bundle's code predates scalar type declarations, PSR-4 autoloading conventions as we now use them, and Composer 2 metadata expectations. A composer require will either fail resolution or, worse, resolve against stale transitive pins and drag incompatible Symfony components into the tree.

Sequencing: Treat this as a closed evaluation, not a phased rollout. Step 1: confirm the underlying caching requirement with the requesting team (one conversation, not a spike). Step 2: evaluate the Laravel-native option against that requirement — typically a half-day spike, since middleware and spatie/laravel-responsecache are well-trodden. Step 3: only if surrogate-key invalidation is required, run a two-week spike on fos/http-cache with an in-house provider, scoped to a single low-traffic route. Do not allocate engineering time to this bundle at any point in the sequence.

Operational Impact

Maintenance: Zero upstream maintenance and no path to regain it — the repository is archived, meaning issues and pull requests are closed by policy, not backlog. Any defect we encounter becomes our defect permanently. The 2013 last-release date means the package has missed every PHP and Symfony runtime change of the past decade; there is no version we could pin that is both functional and current.

Support: No vendor, no maintainer, no active user base to consult (0 dependents, 105 stars accumulated over a decade — a negligible fraction of which represent live production usage). Internal support would require an engineer to reverse-engineer 2013-era Symfony idioms, which is a poor use of senior time and creates a single point of failure around whoever does it.

Scaling: Not applicable in the conventional sense — the package manipulates response headers and ESI tags, which are cheap operations. The scaling concern is organizational, not computational: every engineer who touches the caching layer must first learn why an archived Symfony bundle is in a Laravel application. That's a recurring onboarding tax with no offsetting benefit. Cache invalidation correctness, by contrast, does scale in importance — a subtly wrong Vary or Surrogate-Control header under load produces cache poisoning or stale-content incidents that are expensive to diagnose.

Failure modes: The dominant failure mode is the package simply not booting on a modern runtime, discovered at deploy time rather than at dependency-resolution time if autoloading happens to pass. Secondary failure modes are subtler and worse: header-emission logic written against Symfony 2's response object silently no-oping or misbehaving when adapted to Laravel's response, producing cache hits where misses were intended (or vice versa) without throwing. That class of bug surfaces as intermittent stale content in production, attributed to the CDN before anyone suspects the application layer. There is no upstream to file against when it happens.

Ramp-up: Near-zero for the package itself, because the correct decision is not to adopt it. Ramp-up on the recommended alternatives is modest: middleware-based header policy is an afternoon for any mid-level Laravel engineer; spatie/laravel-responsecache is a day including cache-store configuration; fos/http-cache with surrogate keys is the only genuine investment, at roughly one to two weeks including reverse-proxy configuration and invalidation testing.

Recommendation: Reject. The package is deprecated, archived, twelve years stale, framework-incompatible with the target stack, and has zero dependents. Its only value in this evaluation is as a pointer to FOSHttpCacheBundle/fos/http-cache for surrogate-cache scenarios. The opportunity score of 1.5 reflects this accurately; the 0.62 composite should be read as a ceiling, not a threshold to argue past. Close the ticket with the Laravel-native alternatives documented above and re-scope the underlying caching requirement with the requesting team.