Get Header Laravel Package

Product Decisions This Supports

• Build vs. buy for HTTP header inspection. This package is the "buy" option for a narrow capability: fetching and parsing response headers from a URL (status codes, Content-Type, Location, cache and security headers) without hand-rolling socket or cURL logic. Its existence tells you the need is real and small enough that someone packaged it — and its 33 stars, zero dependents, and archived status tell you the buy option is not viable at scale.
• Roadmap scoping for link/URL-dependent features. If your backlog includes link validation in user-generated content, embed/Open Graph preview generation, redirect-chain auditing, uptime or endpoint health checks, or a security-header checklist, this capability is in scope. The decision it should drive is which dependency owns it — and the answer for a Laravel team is almost always the framework's own HTTP client, not a standalone archived micro-library.
• Feature risk classification. Any feature whose only dependency is unmaintained inherits that risk. If header fetching is on the critical path (e.g., gating file downloads on Content-Type, or verifying a webhook endpoint before enabling it), an archived 2019 library is an unacceptable single point of failure. If it is cosmetic (showing a favicon in a preview card), the risk is tolerable but still not worth taking when a maintained alternative ships with the framework.
• Deprecation and technical-debt triage. For a legacy codebase already calling this package, the decision this supports is a migration ticket, not a renewal: replace with Illuminate\Support\Facades\Http (Guzzle under the hood), which covers redirects, timeouts, custom headers, TLS configuration, and structured response access.
• License review triage. MPL-2.0 is file-level copyleft: you may use it in proprietary products, but modifications to MPL-covered files must be published. That is usually acceptable, but it adds a compliance footnote that a permissively licensed or first-party alternative avoids entirely.

When to Consider This Package

Consider it only when all of the following hold:

• You are maintaining a pre-existing PHP 5.x/7.x application on a 2019-era stack, on a legacy framework or no framework at all, where Guzzle or Composer dependency management is impractical.
• The use is internal, non-customer-facing tooling or a one-off script where you will vendor and freeze the code yourself.
• The behavior you need is genuinely "give me the headers" with no authentication, no retry policy, no connection pooling, and no strict TLS requirements.
• You have read the source, since the archive means no one else will.

Look elsewhere when any of the following apply — which is nearly every case:

• You are on Laravel 8+ or PHP 8+. The package predates both. PHP 8 tightened several language behaviors and bumped cURL/ext expectations; an unmaintained library has no compatibility guarantee, and there will be no fix if it breaks.
• You already have Guzzle. Laravel ships an HTTP client built on it. Http::head($url), Http::withHeaders([...])->get($url), and $response->headers() cover the same ground with maintained code, PSR-18 compliance, retries, and timeouts. Choosing the archived package is choosing a second HTTP stack for no benefit.
• You need the built-in. PHP's get_headers() is a single function call with an associative-array flag. If that is genuinely all you need, you need no dependency at all — which is the strongest argument against this package.
• Security, compliance, or auditability matter. TLS verification defaults, redirect limits, and CRLF-injection handling in a five-year-old unmaintained header parser are unaudited. Anything touching untrusted user-supplied URLs (SSRF surface) should not run through archived code.
• You need a support contract, a CVE feed, or an SLA. Archived means none of these, permanently.

How to Pitch It (Stakeholders)

For executives: We evaluated a small open-source PHP utility for fetching HTTP response headers. It is not a fit. It was last released in 2019, the repository is archived with no maintainer, it has 33 stars and no downstream users, and it does not claim compatibility with current PHP or Laravel versions. The capability it provides — checking a URL's status and headers — is already built into our framework, so adopting it would add a third-party dependency, a license review item (MPL-2.0, file-level copyleft), and an unpatched security surface in exchange for zero functional gain. Recommendation: no adoption; no cost to this decision because the replacement is already in the stack.

For engineering: Use Laravel's HTTP client. Http::timeout(5)->withoutRedirecting()->head($url) gives you status, Location, and headers, with retries, TLS configuration, and a maintained Guzzle foundation. If you need raw get_headers() semantics for a script, call the built-in. Do not vendor yakeing/get_header into new work; if it already exists in our codebase, open a migration ticket — the replacement is a handful of lines, so the swap cost is hours, not sprints.

For product: The feature areas that need header inspection — link health, preview cards, endpoint verification, security-header checks — are all supported today without this package. Nothing on the roadmap should be blocked, accelerated, or descoped because of this decision. The one thing to flag is that any feature requiring trusted URL fetching (user-submitted links, SSRF-adjacent flows) needs a deliberate policy on timeouts, redirect limits, and private-IP blocking, which is a design conversation, not a library choice.