Weave Code
Uri Laravel Package
sabre/uri
sabre/uri is a lightweight PHP library for working with URIs per RFC3986. It offers resolve, normalize, parse, build, and split functions for handling relative URLs, comparing URLs, and Windows-style paths. Fully unit tested, with many tests drawn from RFC3986 examples.
Functions for making sense out of URIs.
Frequently asked questions about Uri
- How do I install sabre/uri in a Laravel application?
- Install it with Composer by running composer require sabre/uri. There is nothing to publish or bootstrap: no service provider, facade, config file, or migration is involved. You then import the five namespaced functions directly, for example use function Sabre\Uri\parse; and call them anywhere in your app. Most teams wrap them in a small application-owned class such as App\Support\Uri so call sites stay tidy.
- Does sabre/uri have a Laravel service provider or facade?
- No. sabre/uri is a plain functional PHP library exposing resolve, normalize, parse, build, and split as namespaced functions, with no container bindings or Laravel integration. That is deliberate and generally a benefit, since it adds no boot cost and no configuration surface. If you want dependency injection, create your own thin adapter class and bind that in a service provider instead.
- What is the difference between resolve() and normalize() in sabre/uri?
- resolve() joins a relative reference onto a base URI according to RFC3986, which is what you need for redirect targets and relative links found in crawled pages. normalize() canonicalizes a URI so two spellings of the same address compare equal, for example case-folding the scheme and host and removing dot segments. Neither function validates that a URI is safe to request or redirect to. Use resolve plus normalize for comparison, and keep allow-listing logic in your own code.
- Can sabre/uri replace Laravel's URL generator or parse_url()?
- It complements Laravel rather than replacing it. Laravel's UrlGenerator and router handle named routes and application URLs, while sabre/uri handles RFC3986 joins, canonicalization before comparison, and dirname/basename style arithmetic on arbitrary URLs. The realistic use cases are redirect validation, webhook and callback URL checks, sitemap path handling, and multi-tenant base-path resolution. It is a reasonable replacement for ad hoc parse_url() calls that are wrapped in regex or explode on ? and #.
- Which PHP and Laravel versions does sabre/uri support?
- The package is framework-agnostic, so it has no declared Laravel version constraint and works with any Laravel release running a supported PHP version. Version 3.1.x requires PHP 8.2 or newer. The 3.0.x and 2.3.x lines support PHP 7.4 and up, which matters if part of your fleet is still on older PHP minor versions.
- Is sabre/uri safe for validating redirect or webhook URLs against SSRF?
- No, and it should not be described that way to stakeholders. normalize() canonicalizes a URI for comparison but does not classify it as safe; it will happily normalize an internal address. Open-redirect and SSRF defence still requires your own scheme and host allow-listing plus DNS and resolved-IP checks before any request is made. Treat sabre/uri as a parsing and canonicalization helper that feeds those checks, not as the check itself.
- How do I test code that uses sabre/uri in a Laravel project?
- Because the functions are pure and stateless, ordinary PHPUnit feature or unit tests are enough, with no mocking of HTTP or filesystem. The most effective approach is to test your adapter against RFC3986 example vectors, many of which come straight from the library's own suite. The upstream project is fully unit tested and draws heavily on RFC3986 examples, so those vectors are a reliable starting point. Pin the major version so test expectations do not shift silently.
- Is sabre/uri safe to use with Laravel Octane and queue workers?
- Yes. The library is five pure functions with no static state, no I/O, and no long-lived objects, so there is nothing to reset between Octane requests or queued jobs. It also has zero runtime dependencies, which means no transitive conflict surface and no PSR-7 or IDN packages pulled in. That makes it one of the safer leaf dependencies to add to a worker-heavy application.
- What are the alternatives to sabre/uri for URL handling in PHP?
- The main alternatives are league/uri for a richer, more standards-focused API, or a PSR-7 implementation such as Guzzle, Diactoros, or Symfony's URI classes if your platform standardizes on UriInterface. sabre/uri is intentionally not PSR-7 aware, so it should sit beside that standard rather than replace it. Its advantage is a tiny functional surface with no dependencies, which is why it is already embedded transitively in the sabre/dav and sabre/http ecosystem.
- Is sabre/uri actively maintained, and what breaking changes should I watch for?
- It is a mature, low-churn library rather than a fast-moving one, so the practical risk is behavioural drift across majors rather than abandonment. Windows file:///C:/ path handling changed in 2.2.3, was reverted in 2.2.4, and was re-introduced as a breaking change in 3.0.0, so pin the major and re-run your adapter tests on upgrade. Registry-dependent counts are unreliable for a library this embedded, so confirm transitive reliance through your own dependency graph. Name an owner for your adapter and a fallback (PSR-7 or league/uri) before adopting, not after.
Weaver
How can I help you explore Laravel packages today?