Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129569 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 4D56A1A00BC for ; Sun, 7 Dec 2025 16:51:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1765126303; bh=7dS3Mo3IAxfOogBNlNuRB9H52HQZFHFLuduN6iFRJOg=; h=From:To:References:In-Reply-To:Subject:Date:From; b=DljaLH2+9Mrhvuct59iS+LHqX+owp9I8LJhsutumde00SgD/WdNw69orINf3NID6p RxlW/pT1B5spLB8Mb4XivLOGfgeNYtyc5906MwmfOMo/QYpJOVNRzDW2XC8Ne2ohRk u8l3BcJ83/kyqQtxAUCyxaZ+zLorPivSHxSTtswccbps1OSq9axNRA5kV27swsbR1r P2v7P5xrjMR4KHsVesf6LR90l/wyY1n6poL6BbbaQ4fVwcIyJQ8jYke2SivFKFTt/L NS5xShUzJCiznVXjlIYieahWycNga7+50993eP0e41mqwArrE/GgaA5tRrHTa/qwqe V8bl6k0EGPAlA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8A7B4180055 for ; Sun, 7 Dec 2025 16:51:42 +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=1.6 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING, HTML_MESSAGE,PDS_PRO_TLD,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from hedgehog.birch.relay.mailchannels.net (hedgehog.birch.relay.mailchannels.net [23.83.209.81]) (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 ; Sun, 7 Dec 2025 16:51:41 +0000 (UTC) X-Sender-Id: yszpovajlk|x-authuser|juris@glaive.pro Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C5AA522122F; Sun, 07 Dec 2025 16:51:35 +0000 (UTC) Received: from server52.areait.lv (trex-green-9.trex.outbound.svc.cluster.local [100.102.148.76]) (Authenticated sender: yszpovajlk) by relay.mailchannels.net (Postfix) with ESMTPA id C90852212AC; Sun, 07 Dec 2025 16:51:34 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; d=mailchannels.net; s=arc-2022; cv=none; t=1765126295; b=YDwCCgaClZTLlRhFf1e8fxSqiCSuFM+vg2ZHmblWqyiRFJYz+l2h7FbbmxQCgyrfVFdMko v0MOOiWhroyI02UuDFSMJJCEn6bxvrFf5hFPduDopUfaWeXj+xStQUnrTcw3CuUR03loYt 2WAkHrCM1PFekdmvi+GjRfoj1w2jGqICJt8My6wOb1+wB7aSG0ox/Ib5du3DfrfllsGzbc PDawIXLdPLJlNQJ7xPXuobGEPrsCYYxp/CDNOjH8RAab3UfsmZ6WEFrkhitGtwCtRTFgN6 zrx6Rbh9t1EYZzYtushIVBwHWNdiCYcL4fDMBX/zdQGH01OTdyjkCyK089FCxw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1765126295; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=sb5M81UkRYpQrHGHJG+OVAsqkMcQ6DDLzPMhBeorYa0=; b=lsMM/UG9SWZM5KI9xNZF3krcrb1nL0boEL/D2syVmDJQ4sH6NwmewNTFDb0WuKN2tt92Wo mlQw/Awy1v3yw44emOQjGtwXNV6Dd7BEDw9ZdqvyTesnOpJbhvaWeVWMDzewapEI3V7BKO 17thf5B97qrlL4wcpfn6QXgRYSIShrAhYp1Nw97wpYTfjhmpu5DMrxKfjTPThBHElanzeU 2lRIPH7ipab+BjA/NqkLDqFyyWlMsehcsXfFkW+6vl91R+QSH7JrS31amN71JrpWs36kEc bJi4/KV7j/LKWzSZnuOHXvnmyMPuC5lPf6AL4sqzDv7I+7dacvaJIiKbdGtwEg== ARC-Authentication-Results: i=1; rspamd-57b9fc4dc5-csrq6; auth=pass smtp.auth=yszpovajlk smtp.mailfrom=juris@glaive.pro X-Sender-Id: yszpovajlk|x-authuser|juris@glaive.pro X-MC-Relay: Neutral X-MailChannels-SenderId: yszpovajlk|x-authuser|juris@glaive.pro X-MailChannels-Auth-Id: yszpovajlk X-Stop-Slimy: 50d5cc0b1f675514_1765126295735_1119004372 X-MC-Loop-Signature: 1765126295735:580077065 X-MC-Ingress-Time: 1765126295734 Received: from server52.areait.lv (server52.areait.lv [83.149.95.205]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.102.148.76 (trex/7.1.3); Sun, 07 Dec 2025 16:51:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=glaive.pro; s=default; h=Content-Type:MIME-Version:Message-ID:Date:Subject:In-Reply-To: References:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sb5M81UkRYpQrHGHJG+OVAsqkMcQ6DDLzPMhBeorYa0=; b=BOTy2zjy4TVrcgBr+W0YmbabLR FNG6DAT89XCozX7g59Ds29qZZ6F/qOk/DKq9fWSfxx53p3DwX8JJ2jdPZBCXQ7X4qjHEsjW8cBejW ZPm6PUYqgEo0Y5XGKuETZvUxkxggrqxBLWVFSqXjUG5rrM6OWQbiumplgi+ZSfIX4DFtwrxInI3XU cO5YZ7YIdqcMsFZZrY4ySSJhTbwOABWtwpP1TIvyQ44uFwPQsGq0mtaU4DUUcLplJJtYxQ8mwo9u+ O6syPXCmmV4NQxnQ4qVUG7Gb7ElNs7lJTjg5gEoj7fCWw1MvL0mAPxlEyElRHN5ywL2e18MKn4hWT ejVQbpng==; Received: from [77.93.29.116] (port=61517 helo=LAPTOPHKIOPCGI) by server52.areait.lv with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vSHyu-0000000AfZ8-2lJB; Sun, 07 Dec 2025 18:51:32 +0200 To: =?utf-8?Q?'M=C3=A1t=C3=A9_Kocsis'?= , "'PHP Internals List'" References: In-Reply-To: Subject: RE: [PHP-DEV] [RFC] [Discussion] Followup Improvements for ext/uri Date: Sun, 7 Dec 2025 18:51:30 +0200 Message-ID: <007f01dc6799$bd08f3d0$371adb70$@glaive.pro> Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0080_01DC67AA.80926010" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQHg0Ty1FEWd1VKsewRTX1Os4ewzpbUNg1Pg Content-Language: lv X-AuthUser: juris@glaive.pro From: juris@glaive.pro ("Juris Evertovskis") This is a multipart message in MIME format. ------=_NextPart_000_0080_01DC67AA.80926010 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hey, =20 I love to see this RFC. I=E2=80=99ve got a few notes which likely come = from me not understanding the specifications. But I think most users = will not have read them and will not know or care about the differences, = right? =20 1. Query setters and types of their parameter. Quote from the builder = example: =20 ``` ->setQuery("a=3D1&b=3D2"]) ->setQueryParams(["a" =3D> 1, "b" =3D> 2]) // Has the same effect as = the setQuery() call above ``` =20 I=E2=80=99d expect the `setQueryParams` to set the particular params = that I specified instead of overriding all the query (which I=E2=80=99d = expect `setQuery` to do). =20 Maybe it would be possible for `setQuery` to accept string, array and = instances of `*QueryParams`? And `setQueryParams` could either be left = out or override just the selected params? As far as I see, there is no = equivalent `withQueryParams` so there=E2=80=99s no precedent on how such = a method should work, right? =20 Btw I wasn=E2=80=99t able to find docs on the existing Uri classes (had = to look it up in the prev RFC). Is the search broken or are the docs = just not there yet? =20 =20 2. Regarding the interface extraction, is there any difference between = the internal states of `Uri\WhatWg\UrlQueryParams` and = `Uri\Rfc3986\UriQueryParams` objects? I would naively expect not only a = common interface, but a common class. A `QueryParams` that could be = supplied to any of the withers/setters and that would be able to = `->toRfc3986QueryString()` or `->toWhatWgQueryString()` on use not on = instantiation. =20 Similarly with the builders I fail to see why do I need to decide on = `Uri\Rfc3986\UriBuilder` and `Uri\WhatWg\UrlBuilder` at the start = instead of having `Uri\Builder` that could be consumed via = `->buildRfc3986Url()` or `->buildWhatWgUri(). Is that UserInfo thing the = whole dealbreaker? To me all the other parts like specifying host, port = and so on seem spec-agnostic until serialization.=20 =20 =20 3. I agree with Larry that I=E2=80=99d expect `[=E2=80=98key1=E2=80=99 = =3D> =E2=80=98value1=E2=80=99, =E2=80=98key2=E2=80=99 =3D> = =E2=80=98value2=E2=80=99]` to =E2=80=9Cjust work=E2=80=9D. I understand = the issue about having multiple entries with the same keys, but I = don=E2=80=99t think I should have to understand that to successfully = build queries. =20 Maybe another method like `bestEffortFromArray()`could be added that = would supoprt various forms of nested arrays and do whatever is possible = to make them into a query string, similar to how `http_build_query()` = does? I know it=E2=80=99s not perfect, but it would be great to have the = new tooling as easy to work with as the previous, instead of having to = reshape your arrays to fit a particular syntax. =20 BR, Juris=20 ------=_NextPart_000_0080_01DC67AA.80926010 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey,

 

I love to see this = RFC. I=E2=80=99ve got a few notes which likely come from me not = understanding the specifications. But I think most users will not have = read them and will not know or care about the differences, = right?

 

1. Query setters and = types of their parameter. Quote from the builder = example:

 

```

=C2=A0=C2=A0=C2=A0 = ->setQuery("a=3D1&b=3D2"])

=C2=A0=C2=A0=C2=A0 = ->setQueryParams(["a" =3D> 1, "b" = =3D> 2]) // Has the same effect as the setQuery() call = above

```

 

I=E2=80=99d expect = the `setQueryParams` to set the particular params that I specified = instead of overriding all the query (which I=E2=80=99d expect `setQuery` = to do).

 

Maybe it would be = possible for `setQuery` to accept string, array and instances of = `*QueryParams`? And `setQueryParams` could either be left out or = override just the selected params? As far as I see, there is no = equivalent `withQueryParams` so there=E2=80=99s no precedent on how such = a method should work, right?

 

Btw I wasn=E2=80=99t = able to find docs on the existing Uri classes (had to look it up in the = prev RFC). Is the search broken or are the docs just not there = yet?

 

 

2. Regarding the = interface extraction, is there any difference between the internal = states of `Uri\WhatWg\UrlQueryParams` and = =C2=A0`Uri\Rfc3986\UriQueryParams` objects? I would naively expect not = only a common interface, but a common class. A `QueryParams` that could = be supplied to any of the withers/setters and that would be able to = `->toRfc3986QueryString()` or `->toWhatWgQueryString()` on use not = on instantiation.

 

Similarly with the = builders I fail to see why do I need to decide on = `Uri\Rfc3986\UriBuilder` and `Uri\WhatWg\UrlBuilder` at the start = instead of having `Uri\Builder` that could be consumed via = `->buildRfc3986Url()` or `->buildWhatWgUri(). Is that UserInfo = thing the whole dealbreaker? To me all the other parts like specifying = host, port and so on seem spec-agnostic until serialization. =

 

 

3. I agree with Larry = that I=E2=80=99d expect `[=E2=80=98key1=E2=80=99 =3D> = =E2=80=98value1=E2=80=99, =E2=80=98key2=E2=80=99 =3D> = =E2=80=98value2=E2=80=99]` to =E2=80=9Cjust work=E2=80=9D. I understand = the issue about having multiple entries with the same keys, but I = don=E2=80=99t think I should have to understand that to successfully = build queries.

 

Maybe another method = like `bestEffortFromArray()`could be added that would supoprt various = forms of nested arrays and do whatever is possible to make them into a = query string, similar to how `http_build_query()` does? I know = it=E2=80=99s not perfect, but it would be great to have the new tooling = as easy to work with as the previous, instead of having to reshape your = arrays to fit a particular syntax.

 

BR,

Juris =

------=_NextPart_000_0080_01DC67AA.80926010--