Get Header Laravel Package

Technical Evaluation

Architecture fit

yakeing/get_header is a procedural PHP utility, not a Laravel package. It exposes a global-function replacement for PHP's native get_headers() and ships no service provider, facade, config file, contract, or DI bindings. That means it cannot participate in Laravel's container, configuration, or package-discovery lifecycle; it would enter the codebase as a bare function call, which makes it harder to mock, test, instrument, or swap later. It also sits adjacent to — not inside — Laravel's HTTP layer (Illuminate\Support\Facades\Http / Guzzle), so any adoption creates two parallel ways to inspect HTTP headers in one application. For a TPM, the architectural question is not "does it fit?" but "does it earn a dependency?" The answer is no unless we have a documented case where native get_headers() demonstrably fails and Guzzle is unavailable.

Integration feasibility

Integration is technically trivial (likely a single file autoloaded via Composer) and therefore deceptively attractive. The real feasibility constraint is governance: the repository is archived, the last release was 2019-08-06, it has 33 stars, zero dependents, and a composite health score of 0.1275. Zero dependents means no ecosystem validation — nobody else's production traffic has exercised this code. Feasibility for a spike is high; feasibility for a production dependency is low. If we need the behavior, the pragmatic path is to vendor a reviewed copy under our namespace or, better, write a ~30-line internal helper or use Guzzle directly.

Technical risk

• Abandonment risk (high): archived upstream means no CVE response, no PHP-version fixes, no issue triage. We inherit 100% of maintenance.
• Runtime compatibility (medium-high): 2019-era PHP code is a plausible candidate for PHP 8 breakage (removed curly-brace string offsets, each(), loose type handling in header parsing). Must be verified on our target PHP 8.1/8.2/8.3 matrix before any consideration.
• Behavioral risk (medium): reimplementations of get_headers() frequently diverge on redirects, 4xx/5xx handling, timeout defaults, TLS verification, and IPv6. Silent differences from native behavior are the classic failure mode.
• Security (medium): header fetching against user-supplied URLs is an SSRF vector; we would need allow-listing, scheme restrictions, and timeout caps that this library almost certainly does not provide.
• Blast radius (low): small, isolated utility — if it fails, it fails locally rather than corrupting application state.

Net: low blast radius, but an unmaintained dependency with unverified PHP 8 support is an avoidable liability.

Key questions

1. What concrete behavior does native get_headers() fail to deliver for our use case (redirects? non-2xx responses? timeouts? SSL?), and can Guzzle or Laravel's HTTP client cover it?
2. Which PHP and Laravel versions must this run on, and has the code been executed on PHP 8.x?
3. Will URLs be user-supplied? If so, who owns SSRF controls and egress policy?
4. Are we willing to fork, own, and test this code indefinitely, or is this a one-off script?
5. Does legal accept MPL-2.0 file-level copyleft for a vendored/modified copy, and can we preserve license headers?
6. Is there a maintained alternative (Guzzle HEAD request, Http::head(), Symfony HttpClient) that should be preferred by default?

Integration Approach

Stack fit

Poor as a dependency, adequate as a reference. Laravel applications already ship Guzzle via laravel/framework; Http::head($url)->headers() or a Guzzle client with allow_redirects => false and http_errors => false covers nearly every legitimate use of a get_headers-style call, with far better timeout, TLS, proxy, and testing support. The only scenario favoring this package is a non-Laravel, dependency-averse PHP script — which is not our stack.

Migration path

If the capability is genuinely required: (1) isolate the need behind an interface such as HeaderInspector; (2) implement it with Guzzle/Laravel HTTP client first; (3) only if a native-behavior gap is proven, port the specific parsing logic from this package into that implementation, preserving MPL notices; (4) prohibit direct calls to the global function anywhere in application code. Do not migrate to the package; migrate past it.

Compatibility

Framework-agnostic, so Laravel version compatibility is a non-issue — but that also means no framework guarantees. Must be validated against our PHP runtime, ext-curl/ext-openssl presence, and Composer 2 autoloading. Check for a declared php constraint in composer.json; if it caps below 8.0, treat it as incompatible and stop. Also confirm it does not register a global function name that could collide with other legacy code.

Sequencing

1. Discovery (1–2 days): inventory any existing usage; document the exact behavior gap versus native get_headers().
2. Spike (2–3 days): prototype the Guzzle/Laravel HTTP equivalent; compare outputs across redirect, 404, timeout, and TLS-failure cases.
3. Decision gate: adopt a vendored/internal helper only if the prototype cannot match required behavior; otherwise close out with no new dependency.
4. Hardening: if vendored, pin to a commit, add unit tests, add PHP 8 CI coverage, and document ownership.
5. Cleanup: remove the package reference from composer.json if it was ever introduced; avoid leaving a dormant dependency.

Operational Impact

Maintenance

Effectively zero upstream maintenance and full ownership transfer to us on day one. Archived status is a hard stop: no bug fixes, no security patches, no PHP 9 readiness. Budget for periodic PHP-version audits of any vendored copy, and treat it as internal code with an internal owner — not as a third-party dependency with an upgrade path.

Support

No vendor, no SLA, no active issue tracker. Community support is negligible (33 stars, 0 dependents), so Stack Overflow and package-ecosystem answers will be sparse. Internal engineers will debug from source. For a utility this small that is survivable, but it is unbudgeted engineering time that a Guzzle-based approach avoids entirely.

Scaling

It is a synchronous, blocking, per-URL call with no pooling or connection reuse. Fine for a handful of admin-triggered checks; unsuitable for request-path or batch workloads. If header inspection becomes high-volume, the correct answer is Guzzle's Pool or Http::pool() for concurrency, plus caching and a circuit breaker — none of which this package offers.

Failure modes

Expect: silent false/empty returns on DNS or TLS failure; divergent redirect-depth behavior; missing or short default timeouts causing request pile-up; unverified TLS by default in some reimplementations; and SSRF exposure on user-supplied URLs. Because it is a global function, failures are hard to observe centrally — no logging hooks, no events, no metrics. Any adoption requires wrapping it in a service that enforces timeouts, allow-lists, and structured error reporting.

Ramp-up

Technically minutes — it is one function with an obvious signature. The real ramp-up cost is archaeological: understanding why it was introduced, what native behavior it was working around, and whether that workaround is still needed. That knowledge is not in the repo (2019, archived, minimal docs). Document the rationale at the point of introduction or, preferably, eliminate the need by standardizing on the framework HTTP client.