Cache Control Bundle Laravel Package

Product Decisions This Supports

This is a legacy decision-input, not an adoption candidate. It informs three recurring PM choices:

• Build vs. buy on HTTP caching: In its era (Symfony 2.x, ~2011–2013), it answered "do we hand-roll ETag/Last-Modified validation, cache tagging, and reverse-proxy directives, or take a bundle?" The bundle's real value was bundling route-level cache directives, validation, and Varnish/ESI helpers behind annotations — a genuine build-vs-buy shortcut.
• Roadmap sequencing for performance work: Caching is a lever you pull when TTFB or origin load becomes a stated constraint. If a roadmap item is "reduce origin traffic / improve p95 latency," proxy-level caching is the cheapest first move — but that decision now belongs to FOSHttpCacheBundle or a platform/CDN layer, not this package.
• Tech-debt triage: If a codebase already references LiipCacheControlBundle, that's a concrete modernization ticket — Symfony 2→current upgrade, PSR-0→PSR-4, annotation config→attributes/PHP config. This package is a signal for scoping that work, not a solution.
• Use cases it correctly framed then and still frames now: cache validation for public content, per-route cacheability policy, tag-based invalidation for list/detail pages, ESI for user-personalized fragments. Those are the product questions; the tool is replaceable.

What it does not support: any greenfield or forward-looking decision. Zero dependents, archived, last release 2013-12-19, explicitly marked DEPRECATED by its own maintainers in favor of FOSHttpCacheBundle. Opportunity score 1.5 reflects a dead end, not an untapped market.

When to Consider This Package

Consider it only in one scenario: you are maintaining an existing Symfony 2.x application that already has it installed and running, and a migration is not yet funded. In that narrow case, treat it as frozen — pin the version, document it as unsupported, and do not extend it.

Look elsewhere — immediately — if any of the following is true:

• You are starting anything new. Greenfield use is not defensible; the maintainers themselves say so.
• You need a supported Symfony version (3.4+, 4, 5, 6, 7). This package's last release predates all of them; PHP and Symfony compatibility are the blocking risk, not features.
• You have a security or compliance requirement. Archived means no CVE response. For a component that decides what gets cached and served to whom, that's a private-data-leak surface, not just a nuisance.
• You need modern invalidation (tag-based purging, CDN APIs, xkey/cache-tag). FOSHttpCacheBundle plus FOSHttpCache is the maintained successor and the migration guide lives in this package's own README — that README is the most useful artifact here.
• You want caching without adopting a framework bundle: Symfony's built-in HttpCache, a CDN edge layer, or symfony/http-kernel attributes may cover you with less surface area.

Rule of thumb: the only reason to touch this repo is to read its migration guide.

How to Pitch It (Stakeholders)

To executives: This is a deprecated 2013 Symfony bundle with no maintainer, no security response, and no dependents. I am not recommending investment. The relevant finding is the one it points to: HTTP caching is a high-leverage performance lever, and if we want it, we should allocate a small, bounded effort to adopt the maintained successor (FOSHttpCacheBundle) or push caching to the CDN. Separately, if any system still depends on this, that's an unmaintained-component exposure worth a scoped remediation ticket — cheap now, expensive after an incident.

To engineering: Do not add this dependency. Read its README migration guide, then evaluate FOSHttpCacheBundle against our actual Symfony version and hosting model. Before any caching work, we need a stated cacheability policy — which routes are public, private, or fragment-cached, and how invalidation is triggered — because a wrong default serves private data from a shared cache. Effort is small if we scope it to route policy plus validation headers; tag-based invalidation and ESI are phase two. If we already reference this package, log it as tech debt with a Symfony upgrade owner and a target quarter.