Cache Control Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for HTTP cache policy. This package addresses exactly one concern — emitting Cache-Control (plus Pragma/Expires) headers so browsers re-fetch pages instead of serving stale copies. As a PM, the decision it informs is whether a cross-cutting response-header behavior lives in a third-party dependency or in first-party middleware you own. At ~20 lines of middleware and zero maintenance signal upstream (3 stars, 0 dependents), the "buy" case is weak; the package is more useful as a written spec for the behavior than as a dependency.
• Deploy-hygiene roadmap item. The symptom that drives this need — "users are seeing the old version after deploy" — should trigger a roadmap conversation about cache-busting strategy: hashed asset filenames and versioned URLs (Vite manifest in Laravel) versus blanket no-cache headers. These are different problems with different fixes, and the package only addresses the blunt one.
• Support-ticket triage. If stale-content complaints are recurring, this package is one candidate remediation and also a way to size the problem (ticket volume, browsers/proxies affected) before committing to a surgical per-route policy versus a global one.
• Framework-fit gating for package intake. Despite being catalogued among Laravel/PHP packages, this is a Symfony2 bundle, not a Laravel package. It will not install or function in a Laravel app — no service provider, no middleware discovery, no effect at runtime. For intake/approval decisions, it's a clean example of "concept transfers, code does not."
• Modernization sequencing. Adopting Symfony2-era code with no maintainer creates a line item in every future framework upgrade. That lifecycle cost belongs in the decision record before the dependency is introduced.

When to Consider This Package

Consider it only when all of the following hold:

• The application is a legacy Symfony 2.x codebase in maintenance mode with no near-term upgrade planned.
• The requirement is a uniform, site-wide no-cache policy — no per-route or per-content-type nuance.
• Engineering capacity is effectively zero and a drop-in bundle is the only realistic path this quarter.
• You've accepted the risk of an unmaintained dependency with no downstream users to surface regressions.

Look elsewhere — or build in-house — when:

• Any modern Symfony (4+/5+/6+) or Laravel runtime is in play. For Laravel the equivalent is a middleware that sets headers on the response; for modern Symfony it's a kernel response listener. Both are a few dozen lines and can be tested alongside your ETag/Vary and security headers.
• You need granularity. Blanket no-cache on every page is a real performance and cost tax — it multiplies origin traffic, defeats CDN offload, and can regress Core Web Vitals. Marketing pages, product pages, static assets, and API GETs usually want different policies.
• Header correctness is business-critical. Cache-Control, Vary, ETag, HSTS, and CSP need to behave coherently, and that's a first-party concern with tests and a clear owner.
• Security/compliance review applies. An unmaintained package touching response headers should fail most supply-chain gates.
• The actual problem is asset versioning. If stale JS/CSS is the complaint, hashed filenames and cache-busted URLs fix it without penalizing HTML caching.

Recommendation to carry into the decision record: do not adopt as a dependency. Treat this package as a reference implementation for the headers you want, and fund a small first-party middleware with explicit per-route policy, tests, and an owner.

How to Pitch It (Stakeholders)

To executives: We evaluated a small open-source component that disables browser caching across an entire site, to address "users are seeing an outdated version" complaints. It does one narrow thing and does it bluntly — and it's an essentially unmaintained Symfony2-era library (3 GitHub stars, zero dependent projects), so it carries disproportionate long-term risk for the value delivered. Turning off caching everywhere would also raise infrastructure cost by pushing traffic a CDN currently absorbs. Recommendation: don't take the dependency; replicate the behavior in roughly a day of first-party work with proper per-page control. Net effect: same user-facing fix, lower run cost, and no orphaned dependency at our next framework upgrade.

To engineering: The package's behavior is a response-header policy — set Cache-Control: no-cache, no-store, must-revalidate (plus legacy Pragma/Expires) on outgoing responses. In Laravel that's a global or route-scoped middleware; in modern Symfony it's a kernel response listener. I'd like us to own it rather than vendor it, because (a) it needs to be selective by route and content type rather than global — blanket no-store on static assets and API GETs silently disables CDN caching and is usually a defect, not a feature; (b) it should be tested alongside our ETag/Vary and security headers, and verified with curl -I against representative routes plus a check that CDN behavior hasn't regressed; and (c) upstream shows no maintenance signal and would become a blocker at our next framework upgrade. Scope estimate: one small middleware, a route-level config flag, and tests — a sub-day change that shouldn't occupy a sprint slot. Please flag if you see a constraint that makes the vendored bundle genuinely cheaper.