Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:124077 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: by qa.php.net (Postfix, from userid 65534) id 33C961ADA79; Sun, 30 Jun 2024 06:51:53 +0000 (UTC) To: internals@lists.php.net,Stephen Reay Message-ID: <07160e83-7333-44a1-81f2-b121e2cf0ffd@gmail.com> Date: Sun, 30 Jun 2024 08:51:52 +0200 Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Reply-To: nyamsprod@gmail.com Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API References: <71a73b87-cc2f-4ee5-a961-7bf2b191fbb6@gmail.com> <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com> Content-Language: fr In-Reply-To: <5159E0AB-C8B0-4A54-9654-986C1D9C858F@koalephant.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 94.225.114.231 From: nyamsprod@gmail.com (ignace nyamagana butera) On 29/06/2024 11:57, Stephen Reay wrote: > > >> On 29 Jun 2024, at 04:48, Niels Dossche wrote: >> >> - It's a bit of a shame that the PSR interface treats queries as strings. >> In Javascript we have the URLSearchParams class that we can use as a key-value storage for query parameters. >> This Javascript class also handles escaping them nicely. > > Agreed this is a weird choice to me, but I'm also not surprised by weird choices via > php-fig (log level constants I'm looking at you) > > We hear all the time how userland is more flexible and can change quicker - and yet here we see a potential built in class having a worse api because it wants to be compatible with an existing userland interface with the same bad api.... > > Cheers > > Stephen While I do not think the debate should be about compatibility with PSR-7 some historical context shoyld be brought to light for a fair discussion: - parse_url and parse_str predates RFC3986 - URLSearchParans was ratified before PSR-7 BUT the first implementation landed a year AFTER PSR-7 was released and already implemented. - PHP historical query parser parse_str logic is so bad (mangled parameter name for instance) that PSR-7 was right not embedding that parsing algorithm in its specification. - If you take aside URITemplate specification and now URLSearchParams there is no official, referenced and or agreed upon rules/document on how a query string MUST or SHOULD be parsed. - Last but not least URLSearchParans encoding/decoding rules DO NOT follow either RFC1738 nor RFC3986 (they follow the form data which is kind of a mix between both RFC) THis means that just adding a method or a class that mimic 100% URLSearchParans for instance will constitute a major departure in how PHP trears query string you will no longer have a 1:1 relation between the data you have inside your `_GET` array and the one in UrlSearchParams for better or for worse. For all these arguments I would keep the proposed `Url` free of all these concerns and lean toward a nullable string for the query string representation. And defer this debate to its own RFC regarding query string parsing handling in PHP.