Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127307
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <CAH5C8xVquAMhQyrmnsBhnHtVrTpvC1+iW=pGf7EM0sHAGuAXeA@mail.gmail.com>
Date: Wed, 7 May 2025 14:16:11 -0500
Cc: PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <E34BD802-5B71-4D42-91AC-53CCAEFF92DC@pmjones.io>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <CAH5C8xVquAMhQyrmnsBhnHtVrTpvC1+iW=pGf7EM0sHAGuAXeA@mail.gmail.com>
To: =?utf-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>
From: pmjones@pmjones.io ("Paul M. Jones")

Hi Mat=C3=A9 and all,

> On May 5, 2025, at 16:36, M=C3=A1t=C3=A9 Kocsis =
<kocsismate90@gmail.com> wrote:
>=20
> Hello Internals,
>=20
> 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.
>=20
> 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.
>=20
> 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=C3=A9'=
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=C3=A9 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 =E2=80=9Cgetter steps=E2=80=9D that are defined by =
the specification, but the individual components are returned directly =
without any other changes that the =E2=80=9Cgetter steps=E2=80=9D 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