feat(support)!: use PHP 8.5 native URI parser

[boydbloemsma]

Fixes: #1641

[github-actions]

Benchmark Results

Comparison of feat/new-core-uri-implementation against 3.x (dae32bb2a607df2fac7c755a8f6344ea4bf8af84).

Open to see the benchmark results

Benchmark	Set	Mem. Peak	Time	Variability
ViewRenderBench(benchExpressions)	-	24.567mb 0.00%	463.907μs -8.65%	±0.92% +23.28%
DiscoveryScanBench(benchFullDiscoveryScan)	-	25.028mb +0.02%	18.818ms +7.20%	±2.54% +355.65%
GenericRouteMatcherBench(benchMatch)	Dynamic	4.529mb +2.03%	4.050μs +19.15%	±0.28% -74.09%
GenericRouteMatcherBench(benchMatch)	Non existing long	4.529mb +2.03%	3.073μs +25.52%	±0.36% -49.71%
GenericRouteMatcherBench(benchMatch)	Non existing short	4.529mb +2.03%	2.870μs +29.73%	±0.41% -67.06%
GenericRouteMatcherBench(benchMatch)	Static route	4.529mb +2.03%	1.990μs +43.25%	±1.48% +36.92%

_{Generated by phpbench against commit e8d7d1b}

[xHeaven]

Other than this, LGTM! The benchmark numbers are expected (and much better now), parse_url is more performant in general.

[brendt]

I'm trying to decide whether this is breaking or not. We now follow the spec that "an empty path" still needs a /, and some of the existing tests were adjusted accordingly.

Since we only use this URI implementation within the context of requests, my feeling is that this change doesn't have any breaking impact, because the browser will be sending the correct URIs anyway.

Anything I'm missing?

[xHeaven]

I'm trying to decide whether this is breaking or not. We now follow the spec that "an empty path" still needs a /, and some of the existing tests were adjusted accordingly.

Since we only use this URI implementation within the context of requests, my feeling is that this change doesn't have any breaking impact, because the browser will be sending the correct URIs anyway.

Anything I'm missing?

From the Request standpoint, it is not breaking. From the Uri API's standpoint, it's an observable change:

Uri::from('https://example.com')->path; // null → '/'
(string) Uri::from('https://example.com'); // 'https://example.com' → 'https://example.com/'

Callers may rely on the exact string for comparisons, cache keys, signatures, etc. The new parser also changes more than the empty path, because it normalizes hosts and IDNs, strips default ports, and resolves dot segments.

However, as we discussed before, the current behavior is more like a bug. I personally would be fine shipping this as a 3.x bugfix, but I'd mark it as breaking, just for communication's sake.

[brendt]

but I'd mark it as breaking, just for communication's sake.

Agree

[xHeaven]

LGTM!

[brendt]

Merged! Thanks @boydbloemsma , really great PR :)