Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126516
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.400.131.1.6\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
In-Reply-To: <da26554a-ed39-4e80-bcb4-29a46d9fdb61@gmail.com>
Date: Thu, 27 Feb 2025 07:48:02 -0600
Cc: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 "Gina P. Banyard" <internals@gpb.moe>,
 PHP Internals List <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <7B7987C6-37F3-432A-8BA2-9D93F428FAD5@pmjones.io>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <RYUX5rSGApW8lPGs1yovM2fIXXBHd_UcqEKAKgj8-dRrpThS4tC195Jb3kPTT5up96r7SZ2WunauAblAIEkZe41BwZxLeSE2SaKQLAYSmZo=@gpb.moe>
 <811B65CE-1DF0-4A47-937C-4FCB6E945B92@pmjones.io>
 <cf16068b3acf6692172ee0971fcda417@bastelstu.be>
 <19377F60-FB7F-4E6E-A085-4DCB6CD92234@pmjones.io>
 <da26554a-ed39-4e80-bcb4-29a46d9fdb61@gmail.com>
To: nyamsprod@gmail.com
From: pmjones@pmjones.io ("Paul M. Jones")


> On Feb 25, 2025, at 09:55, ignace nyamagana butera =
<nyamsprod@gmail.com> wrote:
>=20
> The problem with your suggestion is that the specification from WHATWG =
and RFC3986/3987 are so different and that the function you are =
proposing won't be able to cover the outcome correctly (ie give the =
developper all the needed information). This is why, for instance, Mat=C3=A9=
 added the getRaw* method alongside the normalized getter (method =
without the Raw prefix).

The two functions need not return an identical array of components; =
e.g., the 3986 parsing function might return an array much like =
parse_url() does now, and the WHATWG function might return a completely =
different array of components (one that includes the normalized and/or =
raw components).

All of this is to say that the parsing functionality does not have to be =
in an object to be useful *both* to the internal API *and* to userland.

Recall that I'm responding at least in part to the comment that =
"Considering that one of the other stated goals of this RFC is to =
provide this API to other core extensions, the previous objections [to =
the Request/Response objects going into core] do not apply here." If the =
only reason they don't apply is that the core extensions need a parsing =
API, that reason becomes obviated by using just functions for the =
parsing elements.

Unless I'm missing something; happy to hear what that might be.


-- pmj