Hpropagate Laravel Package

Technical Evaluation

What it does. vira/hpropagate propagates inbound HTTP headers onto outbound HTTP calls — the classic correlation-ID / W3C traceparent / X-Request-ID / tenant-token propagation pattern. That capability is genuinely valuable and increasingly expected in service-oriented Laravel applications.

The fundamental problem: framework mismatch. This is a Symfony bundle, not a Laravel package and not a framework-agnostic library. Everything that makes it installable and wired-up — the Bundle subclass, the DI Extension, compiler passes, and event subscribers bound to kernel.request/kernel.response — is Symfony Kernel machinery. Laravel does not ship symfony/framework-bundle and does not dispatch those events. The bundle is therefore inert in a Laravel application; only the underlying propagation logic (if it lives in a separate core package, which the repo naming hpropagate-symfony implies) is portable, and that core still targets the Symfony RequestStack and HttpClient contracts rather than Laravel's Request and Illuminate\Http\Client.

Ecosystem validation is effectively zero. Zero stars, zero dependents, score 0. Neither the Symfony package nor its presumed core has downstream consumers. There is no evidence of production adoption, no third-party audit, no release cadence to infer from, and no bug-report trail to read as a de-facto compatibility matrix. For a component that touches authorization headers and cross-service identity, adopting an unvalidated dependency is a security decision, not a convenience decision.

Technical risk.

• Security surface. The value and the danger are the same: it copies inbound headers onto outbound calls. A permissive default allow-list would leak Authorization, Cookie, API keys, or internal hostnames to third-party APIs. Any adoption must be allow-list-only, deny-by-default, with an explicit opt-in per outbound client.
• Credential crossover. Propagating an inbound bearer token to an unrelated downstream service is a confused-deputy problem. The upstream Symfony bundle was likely designed for intra-mesh service-to-service traffic; our use case is probably calls to third-party SaaS APIs, where propagation is wrong.
• CRLF / header injection. Header values derived from user-controlled input must be validated before being placed on outbound requests.
• Dependency conflict. Depending on the bundle pulls Symfony components that Illuminate also pins; version constraints can collide with a Laravel app's composer.lock, and resolving them may force unrelated upgrades.
• Stale request context outside HTTP. In queues, scheduled commands, and Livewire/Octane long-running workers there is no inbound request. A request-stack-based design silently propagates nothing, or worse, propagates the previous request's headers.

Key questions for the maintainer (or for us, if the answer is "nobody to ask," which is itself the answer):

1. Is there a framework-agnostic core package, and does it depend on PSR-7/PSR-18 or hard-code Symfony's contracts?
2. What is the default header allow-list, and is it deny-by-default?
3. How is propagation context established outside an HTTP request (jobs, console, queue workers)?
4. What is the supported PHP/Symfony version matrix, and what is the maintenance commitment?
5. Is header propagation applied to all outbound clients, or opt-in per client?

Integration Approach

Stack fit: poor as packaged, good as a concept. Laravel already has first-class primitives this bundle would duplicate: Illuminate\Http\Client global middleware, Http::globalRequestMiddleware(), the Context facade for propagating values across jobs and queued listeners, and Request::header() for read access. A hand-rolled implementation is roughly a service provider plus one Guzzle middleware — small, auditable, and testable in an afternoon.

Recommended path: build, don't adopt — unless the core is framework-neutral.

• Spike first (1–2 days). Read the Symfony bundle's propagation logic and its default header policy. If the core is PSR-7/PSR-18 based and the Symfony layer is genuinely thin, adoption becomes viable. If the logic is welded to RequestStack, close it out and implement in-house.
• If building in-house: define a HeaderPropagator contract in the app layer; implement a Laravel service provider that reads an explicit allow-list from config; register an Http::globalRequestMiddleware() that merges allow-listed headers onto every outgoing PSR-7 request. Add a Context-based fallback for queue jobs. This keeps the pattern in our own codebase with a ~50-line blast radius.
• If adopting: wrap the package behind the same internal contract so application code never references vendor classes. Never let the Symfony bundle appear in app/. Treat it as an implementation detail with a one-file swap point.

Compatibility checks before any commit. Inspect composer.json for symfony/framework-bundle and the Symfony version range; run composer why-not against the target Laravel version; verify the package works with the Laravel-pinned symfony/http-foundation and symfony/event-dispatcher. Confirm behaviour under php artisan queue:work and under Octane (request-scoped state must be flushed per request).

Sequencing.

1. Confirm the actual business driver — is this distributed tracing (correlation IDs, traceparent) or service identity (auth tokens)? They have different risk profiles; tracing is low-risk, identity is high-risk.
2. Prefer the OpenTelemetry PHP SDK / auto-instrumentation if the goal is tracing; it handles context propagation across HTTP, queues, and CLI correctly and is vendor-maintained.
3. If the goal is a lightweight correlation ID, build the in-house middleware.
4. Only evaluate this bundle if steps 1–3 point at it specifically, and then vendor-fork it rather than depending on it.

Operational Impact

Maintenance: assume unmaintained. Zero stars and zero dependents are strong signals of a single-maintainer hobby project. There is no observable release cadence, no security disclosure process, and no migration guide. Any adoption must budget for a hard fork maintained in-house, or accept that a future Symfony major bump breaks it with no upstream fix. Do not add it to a composer.json you don't control.

Support. No community, no vendors, no Stack Overflow corpus. Every defect becomes an internal debugging exercise against unfamiliar Symfony internals. Compare with OpenTelemetry PHP or a 50-line internal middleware, both of which we can reason about unaided.

Scaling.

• Per-request overhead is trivial (a header copy), so throughput is not the concern.
• The real scaling risk is header bloat across hops: propagation chains accumulate baggage, X-Request-ID, and vendor headers; unbounded propagation grows request size and can trip WAFs or upstream header-size limits on long call chains.
• High-cardinality propagated values (user IDs, tenant IDs) can fragment downstream caches if they reach a CDN or shared cache layer.
• Under Octane or Swoole, any request-scoped state held in a singleton is a cross-request data leak — potentially leaking one tenant's auth header onto another tenant's outbound call. This is the single most dangerous failure mode and must be explicitly tested.

Failure modes to instrument for.

• Outbound calls rejected by third-party APIs that validate against unexpected headers (strict CORS/allow-list validators, signed-request APIs where extra headers break the signature).
• Auth token leaked to an external host — high severity, hard to detect after the fact; mitigate with a hard deny-list and an assertion in tests that external clients never receive Authorization.
• Trace context lost in queued jobs and scheduled commands.
• Self-calls (app calling its own API) causing propagation loops and duplicate X-Request-ID chains.
• Silent no-op: propagation configured but never applied because the client used raw Guzzle or file_get_contents instead of the Http facade.

Ramp-up. Low for a Laravel engineer to implement and understand the pattern; moderate-to-high to debug the Symfony bundle's wiring if adopted, because the team has no Symfony Kernel familiarity and the failure modes are silent rather than loud. The asymmetric cost — cheap to build, expensive to debug when headers leak — argues strongly for the in-house route.