Proxy Url Rewrite Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy vs. configure for reverse-proxy URL handling. This package addresses a narrow, recurring problem: applications behind a load balancer, CDN, or ingress generate absolute URLs (redirects, asset links, canonical/SEO tags, OAuth redirect_uri, password-reset and notification links) using the internal scheme/host instead of the public-facing one. The decision it informs is whether to solve that in the app framework, at the edge (nginx proxy_redirect, X-Forwarded-Prefix), or via a library — and this package is a data point for the "library" option.
• Infrastructure modernization roadmap. Relevant when planning containerization, Kubernetes ingress, blue/green or canary deploys, or moving TLS termination to an edge proxy. Any of these changes the externally visible origin and can silently break outbound URLs; this is the class of change the package is designed to absorb without application code edits.
• Path-prefix and multi-tenant routing decisions. If the product may be served under a sub-path (e.g., /app behind a gateway) or a per-tenant hostname, this informs whether URL generation should be config-driven and proxy-aware from day one rather than hardcoded.
• Platform/stack decisions in mixed PHP estates. The package is a Symfony bundle, not a Laravel package. Its presence in an evaluation set should trigger an explicit decision: standardize proxy handling per framework (Laravel's TrustProxies + URL::forceScheme/forceRootUrl) versus adopting a cross-framework convention. For a Laravel-first product, this specific package is not adoptable — the decision it supports is don't vendor it, and instead codify the equivalent behavior in Laravel middleware.
• Legacy Symfony service continuity. Where an existing Symfony application is being placed behind a new gateway and there is no appetite to refactor URL generation, a bundle-level, configuration-only fix has real product value: it de-risks a migration that would otherwise require a code audit of every absolute_url() call site.
• Opportunity signal, not endorsement. A high opportunity score against 5 stars, 0 dependents, and a last release in July 2018 indicates an underserved capability with an unproven implementation. Treat it as evidence the problem is real and commonly felt, not as evidence this artifact is the right answer. The actionable output is usually an internal ~1–2 day implementation or an edge-proxy configuration, not a dependency.

When to Consider This Package

Consider it when:

• The application is Symfony (this is a bundle; it will not drop into Laravel, Lumen, or plain PHP).
• The runtime is PHP 7.x-era with Symfony 3/4. The 2018 release date means PHP 8.1+/8.2+ and Symfony 6/7 compatibility must be verified before any pilot — assume it does not work until proven otherwise.
• The app sits behind a proxy that terminates TLS and/or rewrites the path, and framework-native trusted-proxy configuration is insufficient for generated URLs (not just detected client IP/scheme).
• You need a configuration-only change — no edits to controllers, templates, or mailers — because the codebase is large, frozen, or owned by a vendor.
• You are prepared to fork and vendor the code: pin it, add tests, and own it. BSD-2-Clause permits this, and at this size the fork is cheap.

Look elsewhere when:

• The stack is Laravel. Use TrustProxies middleware plus URL::forceScheme() / URL::forceRootUrl(); this is first-party, maintained, and covers the same ground. Adopting a Symfony bundle here is not feasible.
• You are on a modern Symfony. Native Request::setTrustedProxies() and trusted-header handling in framework.trusted_proxies/trusted_headers generally solve this without a third-party bundle.
• You need maintenance guarantees. Zero dependents, five stars, and no release in ~7 years means no security response, no upstream fixes, and no community triage. In a regulated or customer-facing production path, that is a procurement blocker regardless of license.
• The edge can solve it. Terminating and normalizing at ingress (setting X-Forwarded-Proto/Host/Prefix, proxy_redirect) is often the lower-total-cost fix and keeps the application ignorant of its deployment topology.
• You need broad protocol coverage. Verify it handles Forwarded as well as X-Forwarded-*, port and path-prefix rewriting, and trusted-proxy allowlists; if any are missing, an in-house implementation will be more predictable than patching an abandoned bundle.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source component for a real but unglamorous problem — keeping links, redirects, and login callbacks correct when our application runs behind a load balancer, CDN, or gateway. Getting this wrong produces broken password-reset emails, failing SSO/OAuth logins, and SEO-visible canonical URL errors, and it is a classic cause of "works in staging, broken in production" incidents during infrastructure migrations. The component itself is not a viable dependency for us: it is Symfony-only, last released in 2018, has no downstream users, and carries no maintenance commitment. Recommendation: do not adopt; budget roughly one to two engineering days to implement the equivalent behavior natively in our framework's middleware and document the trusted-proxy contract as part of the deployment standard. This captures the benefit at lower long-term risk and avoids a fork we would have to maintain indefinitely.

For engineering leads: The problem is legitimate and the pattern is worth codifying: derive the externally visible scheme, host, port, and path prefix from trusted forwarded headers, and ensure all generated absolute URLs honor them — not just request introspection. The bundle is a useful reference implementation for that logic and a checklist of edge cases (path prefixes, non-default ports, redirect base URLs). It is not a dependency: no PHP 8.x/Symfony 6+ support, no tests or CI we can rely on, no release cadence. Concretely — in Laravel, implement via TrustProxies plus forceScheme/forceRootUrl and cover it with tests that assert generated URLs under simulated X-Forwarded-* headers; in Symfony, prefer native trusted-proxy configuration. Either way, constrain the trusted-proxy allowlist explicitly — misconfigured trust of forwarded headers is a host-header-injection and cache-poisoning vector, and that risk is ours to own whether we write the code or import it.