Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129495 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 1FC271A00BC for ; Mon, 1 Dec 2025 22:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1764629626; bh=bNygbLwxggoHh8XvebkQirhBbSo3ztjj5DPEtdgCuNQ=; h=References:In-Reply-To:From:Date:Subject:To:From; b=lwDHuN3ar8nFzRZ9Q08RrXlPyggB6N2JB3H16tqEkqZ5uzAwO+jf6XV/AeEoq0vle 9DN4apAkZ8kA8dtuJHda3I43ULvr7O/kESQMcFaAgbQrDqUIOy3gSNCNcPdt1hHPRa FeAXSGP+OQVivXAvn5q9LG1rw/AN9VoMbj8N+pRHmBR4JDOG0VRc0XC5HEOxB0LyNy MRhS10DhPUdofG6ROebkZH0k2re+YYGSqZ0VqSePm+aHnAoaKESSA9oJM/NfvVJogh qnxMcCCQ0Zwy2O4GsCwUFnhHiDn2Qp7nHPHEGQLtzbCfUKYpBlMAFySOi4go+rhmca +ehB3aEMKllLQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 687681801DA for ; Mon, 1 Dec 2025 22:53:45 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.41]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 1 Dec 2025 22:53:44 +0000 (UTC) Received: by mail-ot1-f41.google.com with SMTP id 46e09a7af769-7c76f65feb5so3430657a34.0 for ; Mon, 01 Dec 2025 14:53:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1764629619; x=1765234419; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=kK5pXjC9hMkkE3eEIc2NpPSAgzSEIV9iqYpRkes2VPg=; b=UjRUMUcP1qwzSjZzN4bealVeihRQ3EOyoEv9n0xLiho9LfXA23pWBHNN0vCvd3VW1R YwEG/BizODfI6A5iHn2R8xKJc3+8VT4ZFiw2K3+FG1RG1GX/LyvZmeKdRFwb4iEk/Gth 8iVl+pc+00is67iHwad9PtAE5iLnJHic0Y6FkU/DkISOxR37Cnxm82cqn15ZzOeUfvWf CEOsICIuZKfC0MXFIP5P+uBY2IvRCTwmYi28mR74p5Wb5XmFN+ycsQzSEf6WwHPTDXlw DdGiEN2bo1JfHUBgfo/K9HYRaP3aYm0GiqCpOLXtYKiBLWF2FrmNF/0CfbKR8s0TZDst FjYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764629619; x=1765234419; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kK5pXjC9hMkkE3eEIc2NpPSAgzSEIV9iqYpRkes2VPg=; b=K3hKfJyuQPeQNnyk9Ud77O5Y9TtsugS7RTZroTNfYUt92NncdXUpLwh0p906FB21k7 pLw7fHKjBblO0hlDTaxVLUVej3c8ZgmYGIu3OREQWE/x1WiyDLzH2tPZQngUcGioyEo5 WoBAlFvxcdT4paTKbuvkmGutJMUrb1qDwAJ9/5YuCdQ+cH/A5skUNQWnH7qY1JPfUdMk XFwguR4L8cNuhRMQVBoN1z802K+mRLH7SV7sBvsKpqUE/i2r171c7Ny+V00wnefQwgYM 1RSYTApuQ5xAfO5I/o/ipk5NxzUUaBOjaBKYzw/B6CdpTLIJrtdqBXS1JAl4PBnzejqu De/g== X-Forwarded-Encrypted: i=1; AJvYcCU83kl1aTLArdCm6KOJ/4ZcerZ5m3cFI7kA5QPQ84dj9/6IOY3K2nOIMuhNmdUv8O1TwhU4eBlbiaM=@lists.php.net X-Gm-Message-State: AOJu0YxXLpR1iJdSgSvWQCo8nWBqZtXabrtPooYmC558eh1IzAP9fqKY LWtNqhWg9It9qJNHsiWSHXDQaho3AL8spr3YdNonICGzhEvPZBtZtQnpV8SxU+Ly6AgwxhlLvlF OYAjc7XesBrmt2GbUvOdTHY65sfiiDhU= X-Gm-Gg: ASbGncvD0Wh68yBYMzKGWiQJPU/JN9Nuinw7qbHBtFLuyAgFj9fQEgRpu/FLgVXqStI trEhEJesefSux6kgx3f8CVWGgOdghO/b14j6EKX0aeFLO34ZVrpVTmYQvDyKX5iiGgfPmzIXsgO yE6dyftPzQ9MkbMhfFrUJ7mdvtcvRKYTJUp3CmQ2Cj7yr3+VZADbYZWq8aYDef3bSbgnURC9gEy GsPvtGW7/Nh2b7L4xVSX1vaZl/2ehwoQVQF+P8OSCcmC5kqbE+mdKYHULto+1jZGM7EoJ+vDlwL 6M4CsUazyGKuaeLQ4CFSBeHDQTa3vA== X-Google-Smtp-Source: AGHT+IEDpyWTRwrginzYPAm1bnpZ4hVAkcZz92SvOYzSHuxoqzSNx1T37O2SeqtVvljPHX81wjP/+QGIQ3pcCj6A0to= X-Received: by 2002:a05:6808:884c:10b0:451:4c8a:25e8 with SMTP id 5614622812f47-4514c8a52e7mr9679262b6e.6.1764629618954; Mon, 01 Dec 2025 14:53:38 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: <9873b03e-1260-44b3-8285-af9511d8766e@app.fastmail.com> In-Reply-To: <9873b03e-1260-44b3-8285-af9511d8766e@app.fastmail.com> Date: Mon, 1 Dec 2025 23:53:28 +0100 X-Gm-Features: AWmQ_bmktV5W_RuXXM8mL0foXSH4hl0IZHYZvGlk6qY93ypb6T6YApidC5MF1Jo Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri To: Larry Garfield , PHP Internals List , =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= Content-Type: multipart/alternative; boundary="00000000000099157d0644ebd94b" From: nyamsprod@gmail.com (ignace nyamagana butera) --00000000000099157d0644ebd94b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Larry, - 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. This comes from the WHATWG specification the isSpecial is how it is named there It really feels like there's an interface to extract here from the > Url/UriBuilder classes. There's literally only one type-specific method > (build()). Yes but the return type is not always the same object (Uri and Url are different so I would be incline not adding a useless interface they are similar yet different) There's a count() method, so shouldn't Ur{i|l]QueryParams implement > Countable? I tend to agree Countable and IteratoAggregate should be implemented IMHO - The fromArray() logic is... totally weird and unexpected and I hate it. > :-) Why can't you support repeated query parameters using nested arrays > rather than gumming up all calls with a wonky format? > I also do not like the fromArray there are 2 ways to represents query parameters either you use the WHATWG spec in which case they are pairs or you use PHP own algorithm (with it's own caveat and have something resemble the result of parse_str which is destructive by essence. I would prefer the named constructor to reflect that. - The sort() method... should it take an optional user callback, or do we > lock people in to lexical ordering? > This is also derived from the WHATWG spec. Adding a callback might be useful but it really then depends on how you represent each query parameter/pairs. - Why both Uri getRawQueryParams() and getQueryParams()? It looks like > they would return the same value, no? (If not, that should be explained.= ) > Because Uri\Rfc3986\Uri already exposes Uri::getQuery and Uri::getRawQuery. - It would be quite convenient of set() and append() returned $this, > allowing them to be chained. +1 I believe that the structure for the query string is the thing that will need more explaining. Once it is correctly settled on the rest can easily be derived from. my 2 cents. On Mon, Dec 1, 2025 at 11:22=E2=80=AFPM Larry Garfield wrote: > 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 > > 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 > > https://wiki.php.net/rfc/url_parsing_api had become by the end. Despite > > my efforts, > > there are still a couple things which need a final decision, or which > > need to be polished/improved. Some examples: > > > > - How to support array/object values for constructing query strings? > > (https://wiki.php.net/rfc/uri_followup#type_support) > > - How to make the UriQueryParams and UrlQueryParams classes more > > interoperable with the query string component (mainly with respect to > > percent-encoding)? > > (https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding) > > - Exactly how the advanced percent-decoding capabilities should work? > > Does it make sense to support all the possible modes > > (UriPercentEncodingMode) for percent-decoding as well > > ( > https://wiki.php.net/rfc/uri_followup#percent-encoding_and_decoding_suppo= rt > ) > > - etc. > > > > Regards, > > M=C3=A1t=C3=A9 > > Thanks, M=C3=A1t=C3=A9. > > Notes as I read through: > > - I really, really hate the "set" prefix on all the methods. It's a > builder object, surely the "set" is implied? > > $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 > (build()). > > - UriQueryParams::hasWithValue(), could that be just hasValue()? You > still need to specify the key anyway, and that's self-evident from the > signature. > > - There's a count() method, so shouldn't Ur{i|l]QueryParams implement > Countable? > > - 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 we > lock people in to lexical ordering? > > - It would be quite convenient of set() and append() returned $this, > allowing 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 arrays > 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 > private. 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 > --00000000000099157d0644ebd94b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Larry,=C2=A0

=C2=A0- Url::isSpecial() Could we come up with a bett= er name here?=C2=A0 "Special" could mean anything unless you know= the RFC; it feels like "real escape string" all over again.This comes from the WHATWG specification the isSpecial is how it is= named there=C2=A0

It really feels like there's an interface to extract here from = the Url/UriBuilder classes.=C2=A0 There's literally only one type-speci= fic method (build()).
Yes but the return type is not alway= s the same object (Uri and Url are different so I would be incline not addi= ng a useless interface they are similar yet different)

=
There's a count() met= hod, so shouldn't Ur{i|l]QueryParams implement Countable?
I= tend to agree Countable and IteratoAggregate=C2=A0should be implemented IM= HO

- T= he fromArray() logic is... totally weird and unexpected and I hate it. :-)= =C2=A0 Why can't you support repeated query parameters using nested arr= ays rather than gumming up all calls with a wonky format?
<= div>I also do not like the fromArray there are 2 ways to represents query p= arameters either you use the WHATWG spec in which case they are pairs or yo= u use PHP own algorithm (with it's own caveat and have something
<= /div>
resemble=C2=A0the result of parse_str which is destructive by ess= ence. I would prefer the named constructor to reflect that.

<= /div>
- The sort() method.= .. should it take an optional user callback, or do we lock people in to lex= ical ordering?
This is also derived from the WHATWG sp= ec. Adding a callback might be useful but it really then depends on how you= represent each query parameter/pairs.

- Why both Uri getRawQueryParams() and ge= tQueryParams()?=C2=A0 It looks like they would return the same value, no?= =C2=A0 (If not, that should be explained.)
Because Uri= \Rfc3986\Uri already exposes Uri::getQuery and Uri::getRawQuery.
=
=C2=A0- It woul= d be quite convenient of set() and append() returned $this, allowing them t= o be chained.
+1

I believe that the stru= cture for the query string is the thing that will need more explaining. Onc= e it is correctly settled on the rest can easily be derived from.
my 2 cents.


On Mon, Dec 1, 2025 = at 11:22=E2=80=AFPM Larry Garfield <larry@garfieldtech.com> wrote:
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
> 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
> https://wiki.php.net/rfc/url_parsing_api had become= by the end. Despite
> my efforts,
> there are still a couple things which need a final decision, or which =
> need to be polished/improved. Some examples:
>
> - How to support array/object values for constructing query strings? <= br> > (https://wiki.php.net/rfc/uri_followup#type_s= upport)
> - How to make the UriQueryParams and UrlQueryParams classes more
> interoperable with the query string component (mainly with respect to =
> percent-encoding)?
> (https://wiki.php.net/rfc/ur= i_followup#percent-encoding_and_decoding)
> - Exactly how the advanced percent-decoding capabilities should work? =
> Does it make sense to support all the possible modes
> (UriPercentEncodingMode) for percent-decoding as well
> (https://wiki.php.ne= t/rfc/uri_followup#percent-encoding_and_decoding_support)
> - etc.
>
> Regards,
> M=C3=A1t=C3=A9

Thanks, M=C3=A1t=C3=A9.=C2=A0

Notes as I read through:

- I really, really hate the "set" prefix on all the methods.=C2= =A0 It's a builder object, surely the "set" is implied?=C2=A0=

$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 Ur= l/UriBuilder classes.=C2=A0 There's literally only one type-specific me= thod (build()).

- UriQueryParams::hasWithValue(), could that be just hasValue()?=C2=A0 You = still need to specify the key anyway, and that's self-evident from the = signature.

- There's a count() method, so shouldn't Ur{i|l]QueryParams impleme= nt Countable?

- As above, there really is an interface lurking in UriQueryParams...

- Why both Uri getRawQueryParams() and getQueryParams()?=C2=A0 It looks lik= e they would return the same value, no?=C2=A0 (If not, that should be expla= ined.)

- The sort() method... should it take an optional user callback, or do we l= ock people in to lexical ordering?

- It would be quite convenient of set() and append() returned $this, allowi= ng them to be chained.

- The fromArray() logic is... totally weird and unexpected and I hate it. := -)=C2=A0 Why can't you support repeated query parameters using nested a= rrays 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.=C2=A0 There doesn't seem to be a justification fo= r the private.=C2=A0 I can't see why new UriQueryParams()->set('= foo', 'bar') is a bad 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?=C2=A0 "Sp= ecial" could mean anything unless you know the RFC; it feels like &quo= t;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
--00000000000099157d0644ebd94b--