Hi Maté and all,
> On May 5, 2025, at 16:36, Máté Kocsis <[email protected]> wrote:
>
> Hello Internals,
>
> After more than a hundred emails refining even the tiniest details, we have reached a point
> where I'd like to call for a vote.
> I know that the new API still doesn't support many use-cases, it still has missing pieces,
> but now it includes a cohesive set
> of functionality that could be a very useful basic building block for most people.
>
> That said, I don't intend to change anything about the RFC anymore, unless there's
> still some factual error in it. There are a lot of
> possibilities how such a large API can look like, and this RFC approaches the problem the way
> it is currently described,
> and not in any other way.
>
> So unless some very serious issues arise, I'm going to start the vote on 8th May, possibly
> in the morning (according to UTC).
I am on record as wanting very much to see some decent web-centric objects in core PHP (Request,
Response, Uri/Url, etc).
To my chagrin, despite the fact that its goals are laudable, I do not think this RFC is in a ready
state to provide such objects.
Among other things I find troubling, the RFC as presented ...
- is too broad in scope;
- acknowledges it is incomplete, with work left undone;
- admits to standards non-compliance; and,
- has an uncertain API.
## Too Broad In Scope
The RFC attempts to do too much at once: not just making URI/URL parsing "pluggable" for
internals, and providing an RFC 3986 compliant parser, but also creating from scratch entirely new
RFC 3986 URI and related Exception classes for userland consumption, along with entirely new
WHATWG-URL classes and Exceptions.
The RFC itself remarks on "[t]he already large scope of the RFC" -- and the same has been
observed during the on-list discussions. Even Maté's message above mentions "There are a
lot of possibilities how such a large API can look like".
It would be better to narrow the scope of the RFC to something more manageable.
## Incomplete, Work Left Undone
This is a consequence of the overly-broad scope. The work remaining is by no means certain to be
completed or voted in after followup RFCs, either on a short timeline or a long one.
Maté notes above that the RFC "has missing pieces" -- and here are some examples from the
RFC itself:
- "Builder classes are not offered by the present RFC just yet. ... this feature is one of the
top candidates of a followup RFC."
- "The topic of query parameter manipulation should be discussed as a followup to the current
RFC."
- "There are multiple planned features in future scope that should be supported."
- "There are immediate plans to add new capabilities to the new API"
- "the position of this RFC is not to include this interface [URLSearchParams] yet"
It would better to present a single finished product instead of multiple partially-finished
products.
## Standards Non-Compliance
The RFC states early on that "the parse_url() function is offered for parsing URLs, however, it
isn't compliant with any standards. ... Incompatibility with current standards is a serious
issue" -- but later it says:
> Getters of Uri\WhatWg\Url have a few gotchas for the ones who are inherently familiar with the
> WHATWG URL specification: they don't (entirely) follow the “getter steps” that are defined
> by the specification, but the individual components are returned directly without any other changes
> that the “getter steps” would otherwise specify.
The RFC doesn't fully follow the WHATWG-URL standard. This is reminiscent of the complaint
regarding parse_url().
Further, "the WHATWG URL specification contains a URLSearchParams interface" but "the
position of this RFC is not to include this interface yet".
It would be better to actually follow the WHATWG-URL standard, and not add a partially-compliant and
somewhat-nonstandard implementation to core.
## Uncertain API
Because of the unfinished work, and because of the "living standard" nature of WHATWG-URL,
the foundation of the API is unsteady:
> WHATWG URL doesn't specify percent-decoding rules for most components .... But since the
> WHATWG URL specification is subject to constant updates, it's possible that normalization or
> percent-decoding rules change in the future.
"Constant updates" makes me think it is too early to include a WHATWG-URL implementation
in core.
Then we have this ...
> the current RFC chooses to make the built-in URI implementations final .... until the new API
> becomes mature enough and becomes tested in practice.
... and this:
> Once the API settles, we plan to lift these restrictions [around final classes] at some extent.
If the API needs to "become tested in practice" so that it can "mature" and
"settle", it would be better do that in userland (maybe published on Packagist or PECL)
instead of in core.
## Remedies
I think all of the above can be remedied, so that we can finally have some decent web-centric
objects in core. But that's a discussion for a later time, one we can have if the RFC does not
pass.
-- pmj