Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129628 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 D3B351A00BC for ; Tue, 16 Dec 2025 21:44:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1765921445; bh=XLuQ19yGpVuNJbnYFxWyN7WQT89fFx3CbM9hF6KujJc=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fh0ZGHruLyJurYSLZ6Pe2J2UR3le5g9FTlUxvNQ2IF8sL409jRo5BM5NyRKqeDXUB NvGhbgebKG25Jravm4wQvJMme1RXTPgu9Ul5LW3meO1KNPQmlWmwqbqjVF9BhF4LgD sA70cLi9SivSf5VvzY6i39ZaBi6kwJHoCL2T1ccIDTDLzlNSFABaE2H8jI8FK+M4u2 zX/WHyYo0OMjwts/lP0YmoMhnJ7xK2n+RhMVrm68Rk/V02I3rUjAzWXSZbS7qpOoyu 5lqDsSPcfLi0ik9kFY7hxdtWM42f1wxwF6CpoqudqYVQbecBAyCvlNHfWlA7gK05vQ LfEP/gboOuKgw== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 1547518038F for ; Tue, 16 Dec 2025 21:44:03 +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.9 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, MANY_SPAN_IN_TEXT,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-qt1-f177.google.com (mail-qt1-f177.google.com [209.85.160.177]) (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 ; Tue, 16 Dec 2025 21:43:59 +0000 (UTC) Received: by mail-qt1-f177.google.com with SMTP id d75a77b69052e-4ee328b8e38so47255741cf.0 for ; Tue, 16 Dec 2025 13:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765921433; x=1766526233; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XLuQ19yGpVuNJbnYFxWyN7WQT89fFx3CbM9hF6KujJc=; b=d3xycQtakvn4pjIZ+O+RlQ0Gn0q5gkWA2AjG7xRkW5s0i6EF97933xjRfL6MfM85tf g7oGKc4La11BVkZChl/teFYyJiW1kGag8JTCiTuFA3KK28rcKFt/y+ENx/GJ/MT6za/C IKsUQpppckA6NOS9B0fvEb4wo/v6iFeLf8RVZubU8BwmvUnYbKP/7aZE32M9IzmBDHFv H/QSnF6fXdQEuejrjlK1PseO4BUIW0hyFvXN5/P7zWKg/2NU4kQ8CgwAb6Uw0KO/7KUF +L9+yz6naPRFTOVNHANj/BsBElb0Gpb5Ivda0sStsZiHBsnFib2M0FoqjCPWgLogH6Jf 1uQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765921433; x=1766526233; h=cc: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=XLuQ19yGpVuNJbnYFxWyN7WQT89fFx3CbM9hF6KujJc=; b=S3cQKeEH6xaH+hHIXW8DuBI43cWm+XmGWPh/hpYe36qfe9uBNKaLCV6xRA3PynDFEC DCc2WCwNeyK945+rNx8B69FlxPpK7kex0fljukRIGfufBg/QCz3C/tHw7LqUS061ihQ8 K1nCEYrI/9C7FXosA/Bf6nnNxGIV1bIn0+iyrPz7MASs2fSMIcDaovFfG1XK2WICuo9I Kw20+VBjcSZcevEcSR/Pc3oXT0GrCfAv3P31Uf6PdERGcRSQIkPdmoRGnpMf+w8QK/EK vsQiTkRTojFqfZGBuazAMIdRZUTpLUJVbLyGOCJXQPob/fQO8A9Fak4gC3ZdKlhe7E83 oNXA== X-Gm-Message-State: AOJu0YwLYNa1sOXy/B3L0kt9RU5fTZLEaVFDusnIpqdupqeP6TYLVMFt Wq1mENR5F2esHoG/yVBoov0R0px/oo01WrkucXrGNGCkIrUyf2Q2qeRfU0Z8dwqmEQWU3OVnQXg sklGh2K7BhWMcf+PN8jd1X5PSM4ae8UNDsdMn X-Gm-Gg: AY/fxX6GchQz3QoAJiiJ/YNXsdAWZnXWRk2K4B0nq3w6kO/YDIzqHeogIANUmm2q6iQ oNyCt1/cULLm5BzJzZap2WMiz6+xKuQJOSrC/pDyoG5Q4KwpRsUsQJ2lWUUXaRhRD6DReTPfC/j 3EQT8GI/Fep8JUU14A8F03WH2Rdvkd6WQtLYIYtmVrTpO80LYaXYNnPWntjXBC+53IkSlXgim28 nw0kON4Xszo3n++nb2hMDuLHNEQJuPy2oDSbQAhdfQH1G+ZOudlccROV52R8ZgyIGs68FY= X-Google-Smtp-Source: AGHT+IGsCvzrohc14/asKwQoyJi+beliq5hlV4jdDw08bqby64eRvrFlliaBtJKv8XmQ8Fvd5nyow4CV6T833bhyJPQ= X-Received: by 2002:ac8:6f0b:0:b0:4ee:24c5:2d7e with SMTP id d75a77b69052e-4f1d0466d80mr225230091cf.7.1765921433207; Tue, 16 Dec 2025 13:43:53 -0800 (PST) Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Tue, 16 Dec 2025 22:43:42 +0100 X-Gm-Features: AQt7F2q9Y8wQJceVOKsifpBaGkcln28rLJJvaUUAdEL4AJBYoayo5Sm2UgWXYD0 Message-ID: Subject: Re: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri To: ignace nyamagana butera Cc: PHP Internals List , Larry Garfield , =?UTF-8?Q?Tim_D=C3=BCsterhus?= Content-Type: multipart/alternative; boundary="000000000000ba468e0646189f60" From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=) --000000000000ba468e0646189f60 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ignace, Currently, in your proposal you have 2 Query objects. This will give the developper a lot of work to understand where, when and which object to choose and why. Is that complexity really needed? IMHO we may end up with a correct API ... that no-one will use. > > Just to reiterate what I wrote to Juris a few days ago: I'm open to unifying the two classes, but I'm just hesitant because of security and evolvability reasons (but the main one is security). With all that in mind I believe a single `Uri\Query` should be used. Its goal should be: > > - to be immutable > - to store the query in its decoded form. > - to manipulate and change the data in a consistent way. > > So far, I imagined the two QueryParams classes to be mutable because one of their main goals is to be able to build (~ mutate) query param list... But otherwise an immutable implementation would be useful for sure. Decoding/encoding should happen at the object boundaries but everything inside the object should > be done on decoded data. > > Yes, that's what I also had to find out based on my experience with implementing the POC, so I completely agree here. On a bonus side, it would be nice to have a mechanism in PHP that allows the application to switch > from the current `parse_str` usage to the new improved parsing provided b= y the new class when > populating the `_GET` array. (So that deprecating `parse_str` can be init= iated in some distant future.) > This last observation/remark is not mandatory but nice to have. > > This is a very interesting remark, and I have not thought about this possibility yet. Generally, I agree with the idea, but my long-term goal (or wish) is to move away from using $_GET and $_POST to access request data in favor of using objects... So I most probably won't deal with trying to implement this idea. However, I'm willing to add a UriQueryParams::fromCurrentQueryString(), maybe even a UriQueryParams::fromCurrentBody() or similar factory methods if people like it. - in respect to `parse_str`, no mangled data should occur on parsing: > > Uh, I completely forgot about this behavior of parse_str(), and I definitely agree that mangling shouldn't happen. - Only accept scalar values, `null`, and `array`. If an object or a resource is detected a `ValueError` error > should be thrown. > > I wasn't sure what to do with objects, but I'm happy to skip their support, especially if they would cause issues. The rest of the suggestions align with my initial plans (maybe with the exception of throwing ValueError -- I wrote TypeError in the related section). - Remove the addition of indices if the `array` is a list. > > Yes, this also aligns with my initial plans. Best regards, M=C3=A1t=C3=A9 > --000000000000ba468e0646189f60 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ignace,

Currently,=
 in your proposal you have 2 Query objects. This will give the developper a=
 lot of work to understand where, when and which object to choose and why. =
Is that complexity really needed? IMHO we may end up with a correct API ...=
 that no-one will use.

=
Just to reiterate what I wrote to Juris a few days ago: I'm = open to unifying the two classes, but I'm just hesitant because of secu= rity and evolvability reasons (but the main one is security).
<= div class=3D"gmail_quote">
With all that in mind I believe a single `Uri\Query` should be used. Its goal should be:

- to be immutable
- to store the query in its decoded form.
- to manipulate and change the data in a consisten=
t way.

S= o far, I imagined the two QueryParams classes to be mutable because one of = their main goals is to be able to build (~ mutate) query param list...
But otherwise an immutable implementation would be useful for sure.

=
Decoding/encoding should happen at the obj=
ect boundaries but everything inside the object should
be done on decode=
d data.

Yes,= that's what I also had to find out based on my experience with impleme= nting the=C2=A0POC,=C2=A0so I completely agree here.

On a bonus side, it would be nice to have a mechanism in PHP th=
at allows the application to switch
from the current `parse_str` usage to the new improved parsing provided by the new class when
pop=
ulating the `_GET` array. (So that deprecating `parse_str` <=
/span>can be initiated in some distant future.)
This last observation/re=
mark is not mandatory but nice to have.

This is a very interesting remark, and I have n= ot thought about this possibility yet. Generally, I agree with
th= e idea, but my long-term goal (or wish) is to move away from using $_GET an= d $_POST to access request
data in favor of using objects... So I= most probably won't deal with trying to implement this idea. However,<= /div>
I'm willing to add a UriQueryParams::fromCurrentQueryString()= , maybe even a UriQueryParams::fromCurrentBody()
or similar facto= ry methods if people like it.

- in respect to `parse_str`, no =
mangled data should occur on parsing:

Uh, I completely forgot about this behavior of pa= rse_str(), and I definitely agree that mangling shouldn't happen.
= 

- Only accept scalar values, `nul=
l`, and `array`. If a=
n object or a resource is detected a `<=
/span>ValueError` error
shoul=
d be thrown.

=
=C2=A0I wasn't sure what to do with objects, but I'm happy to = skip their support, especially=C2=A0if they would cause=C2=A0issues.
<= div>The rest of the suggestions align=C2=A0with my initial plans (maybe wit= h the exception of throwing ValueError -- I wrote
TypeError in th= e related section).

- Remove the addition of indices if the `array`=
 is a list.

Yes, this also aligns with my initial plans.
=C2=A0
<= div>Best regards,
M=C3=A1t=C3=A9
--000000000000ba468e0646189f60--