[13.x] Use new PHP 8.5 RFC 3986 compliant Uri class

[jnoordsij]

Including polyfill for prior PHP versions without native support

See also https://wiki.php.net/rfc/url_parsing_api

Note this should result in generally more safe and consistent code, given the RFC goals. See also https://thephp.foundation/blog/2025/10/10/php-85-uri-extension/.

Implementation notes

• This PR targets master as it has a small chance of breaking some URL parsing due to now employing a stricter parser. All refactored occurences to me look like they should be complying with such standards, so setting this higher bar seems reasonable.
• Per [13.x] Use new PHP 8.5 RFC 3986 compliant Uri class #58132 (comment) it might also be worth considering using Uri\Whatwg\Url instead in some cases; I'm open to feedback on this choice on a per-case basis!
• Illuminate\Foundation\resources\server.php uses feature detection rather than polyfilling due to the 'minimal' nature of this file.
• Refactoring of the parse_url call in the ConfigurationUrlParser class has been omitted, due to not passing some complex test example after basic refactoring. As this class is designed to parse DB connection urls, which may not necessarily be compliant with stricter specifications, it is questionable whether or not this should be attempted. It is also unclear whether or not the tested example is actually a valid connector url or is also denied when used with real life DB engines. Any undertaken progress on my end can be found at jnoordsij@8c2342b; anyone is free to follow up on this.

[GrahamCampbell]

I think this would be best targetted at Laravel 13. People may also find it unexpected to be forced into RFC 3986, and expect parsing to be more forgiving.

[nyamsprod]

@jnoordsij thanks for the bug report in the puri-olyfill. While I am a proponent advocate of compliance everywhere it is not always the best route. I did take a quick glance at this PR and I believe you need to be aware of some caveats with the PHP native implementations.

Uri\Rfc3986\Uri:

This Uri object does not support i18n: So if for whatever reason a host like bébé.be is fed to your code, Uri\Rfc3986\Uri will throw an exception, parse_url will not. It may parse it wrongly too bug it will parse it 😄 . The Uri object also always expect well encoded components. If the component is not correctly encoded (ie no UTF-8 like characters are permitted anywhere) an exception will be thrown.

if you opt to use Uri\Whatwg\Url

Since Laravel is a web first framework , this is also a valid option. But again, there are some limitations. While the Url object supports i18n, it always requires absolute URI (aka scheme MUST be present always) this also is not the case for parse_url.

So while I understand the need of using modern PHP I would be cautious during the PR review to take into account these informations. One does not move away from parse_url that easy, hence why during the RFC period noone suggested its deprecation.

[jnoordsij]

@nyamsprod thanks for sharing your expertise on the matter. As @GrahamCampbell already rightfully pointed out, the fact that this refactoring does actually go paired with a change in behavior does probably warrant targeting the next major release.

I've already been seeing this in tests of the db url parser, which requires some more changes or potentially should be skipped entirely for this reason. So I'll likely follow up by introducing some more incremental changes and some more thoughts/reasoning on wether or not refactoring is warranted on a per-case basis.

[lucasmichot]

Why not simply use Illuminate\Support\Uri ?

[shaedrich]

Why not simply use Illuminate\Support\Uri ?

This, in turn begs the question whether \Illuminate\Support\Uri should be refactored to be a wrapper around \Uri\Rfc3986\Uri

[jnoordsij]

On second look I'm slightly afraid that this might still be altering behavior in a too prominent manner maybe; e.g. the allowed values for APP_URL might really differ from the original implementation. I'll return this to draft, hoping to come up with a cleaner and most importantly better tested implementation for this.

Implementing this all into \Illuminate\Support\Uri, then adding a proper set of tests there and using subsequent helpers might indeed be the way to go.

If anyone else feels like completing this with some more exploring of the pros and cons, feel free to do so.