Http Headers Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on response-header management. The capability on offer — declare custom HTTP response headers in configuration and have them applied to every response — is roughly a 20–40 line kernel.response event listener in Symfony, or a single middleware in Laravel. This package is the "buy" option, and the buy option here is a 2015-era Symfony 2 bundle with 8 stars, 0 dependents, and no release in roughly a decade. The decision it most cleanly supports is build: replicate the pattern, not the dependency.
• Security and compliance header rollout. If the roadmap item is HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, or a CSP rollout, header handling is a security-critical path. A package last released in 2015 cannot be relied on for PHP 8 compatibility, Symfony 5/6/7 support, or CVE responsiveness. Route this to either a maintained equivalent (e.g., nelmio/security-bundle for the security subset) or first-party code.
• White-label / multi-tenant header injection. Where the real product need is per-tenant or per-environment header sets (branding headers, cache directives, custom correlation/tracing IDs), config-driven header definitions are genuinely useful. But that value lives in the configuration model, not this artifact — it can be reproduced in-house with full ownership.
• Roadmap de-risking. Any item that touches this package should be scoped as a replacement task, not an enhancement task. Budget migration effort, not feature effort.
• Vendor screening signal. Score 0.07 with 0 dependents is a useful calibration data point for the team's dependency-evaluation rubric: it should have failed the gate on maintenance recency and ecosystem adoption before reaching a build-vs-buy conversation.
• Platform-fit correction. Despite being surfaced under a Laravel/PHP package evaluation, this is a Symfony bundle and is not usable in Laravel. The correct product decision is to reject it on framework fit alone and close the evaluation, rather than continue comparing it against Laravel middleware options.

When to Consider This Package

Adoption criteria are narrow and mostly historical:

• You are maintaining a legacy Symfony 2.x or early 3.x application where this bundle is already installed and working, and the header configuration is non-trivial enough that rewriting it carries real regression risk.
• The application is pinned to a PHP/Symfony combination the bundle already runs on, with no near-term upgrade planned.
• Headers change frequently and per-environment, and the team values YAML-declarative configuration over code, with no appetite to own a listener.
• You need arbitrary custom headers (not just the standard security set), and the current behavior is verified by tests you trust.

Look elsewhere — or build in-house — when:

• The target is Laravel or any non-Symfony framework. Hard stop.
• The target is Symfony 4+ or PHP 7.4+/8.x. No release since November 2015 makes compatibility unlikely and support nonexistent.
• The headers are security-relevant. Use a maintained, audited package or framework-native configuration; do not put CSP/HSTS delivery on an unmaintained dependency.
• You need any form of vendor support, security patching, or community answers. 8 stars and 0 dependents means no safety net and no Stack Overflow surface.
• The requirement is simple enough to be a middleware or event listener — which, for essentially all header use cases, it is.

How to Pitch It (Stakeholders)

For executives: We evaluated this package and recommend against adopting it. It is unmaintained — last release November 2015 — has negligible community adoption (8 stars, zero dependent projects), and is a Symfony-only component that does not apply to our Laravel stack. The capability it provides, attaching custom HTTP headers to responses, is small and well-understood: we can implement it ourselves in under a day and own it outright. Adopting this instead would create a permanent maintenance and security liability in exchange for saving a few hours of work. The recommendation is a no-go, with first-party implementation as the path forward.

For engineering: The idea is worth keeping — declarative, per-environment header definitions applied centrally to all responses is a clean pattern for security headers, cache policy, and tracing IDs. The artifact is not: Symfony 2-era bundle, no PHP 8 or modern Symfony support, no maintainer, no dependents. Implement it as a kernel.response listener (Symfony) or middleware (Laravel), driven by config, with a test asserting the exact header set on a sample response. If you need the standard security header set specifically, evaluate nelmio/security-bundle as the maintained alternative rather than hand-rolling CSP. If any legacy service already depends on this bundle, treat it as technical debt and schedule replacement alongside the next framework upgrade rather than as standalone work.