Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129493
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 01 Dec 2025 16:18:45 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <9873b03e-1260-44b3-8285-af9511d8766e@app.fastmail.com>
In-Reply-To: 
 <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
References: 
 <CAH5C8xXUPKgd0wWwLC3G2Ye=kRZN58gK3DY82v5GoduBNNtb5A@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Dec 1, 2025, at 2:50 PM, M=C3=A1t=C3=A9 Kocsis wrote:
> Hi Everyone,
>
> I'd like to introduce my latest RFC that I've been working on for a=20
> while now: https://wiki.php.net/rfc/uri_followup.
>
> It proposes 5 followup improvements for ext/uri in the following areas:
> - URI Building
> - Query Parameter Manipulation
> - Accessing Path Segments as an Array
> - Host Type Detection
> - URI Type Detection
> - Percent-Encoding and Decoding Support
>
> I did my best to write an RFC that was at least as extensive as=20
> https://wiki.php.net/rfc/url_parsing_api had become by the end. Despit=
e=20
> my efforts,
> there are still a couple things which need a final decision, or which=20
> need to be polished/improved. Some examples:
>
> - How to support array/object values for constructing query strings?=20
> (https://wiki.php.net/rfc/uri_followup#type_support)
> - How to make the UriQueryParams and UrlQueryParams classes more=20
> interoperable with the query string component (mainly with respect to=20
> percent-encoding)?=20
> (https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding)
> - Exactly how the advanced percent-decoding capabilities should work?=20
> Does it make sense to support all the possible modes=20
> (UriPercentEncodingMode) for percent-decoding as well=20
> (https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_s=
upport)
> - etc.
>
> Regards,
> M=C3=A1t=C3=A9

Thanks, M=C3=A1t=C3=A9. =20

Notes as I read through:=20

- I really, really hate the "set" prefix on all the methods.  It's a bui=
lder object, surely the "set" is implied? =20

$builder->scheme('https')->host('example.com')->path('/foo/bar')->build(=
);

That's nice and easy to read.

- It really feels like there's an interface to extract here from the Url=
/UriBuilder classes.  There's literally only one type-specific method (b=
uild()).

- UriQueryParams::hasWithValue(), could that be just hasValue()?  You st=
ill need to specify the key anyway, and that's self-evident from the sig=
nature.

- There's a count() method, so shouldn't Ur{i|l]QueryParams implement Co=
untable?

- As above, there really is an interface lurking in UriQueryParams...

- Why both Uri getRawQueryParams() and getQueryParams()?  It looks like =
they would return the same value, no?  (If not, that should be explained=
.)

- The sort() method... should it take an optional user callback, or do w=
e lock people in to lexical ordering?

- It would be quite convenient of set() and append() returned $this, all=
owing them to be chained.

- The fromArray() logic is... totally weird and unexpected and I hate it=
. :-)  Why can't you support repeated query parameters using nested arra=
ys rather than gumming up all calls with a wonky format?

- It's not clear how one would start a new query from scratch, with the =
private constructor.  There doesn't seem to be a justification for the p=
rivate.  I can't see why new UriQueryParams()->set('foo', 'bar') is a ba=
d thing.

- Type support: Looks reasonable to me.

- The HostType logic seems reasonable to me.

- Url::isSpecial() Could we come up with a better name here?  "Special" =
could mean anything unless you know the RFC; it feels like "real escape =
string" all over again.

Some parts of this are over my head as I've not read the relevant RFCs, =
but overall I do like the direction.

--Larry Garfield