Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127213
Message-ID: <acd327bb-e7a8-4605-9562-1848720ffea0@bastelstu.be>
Date: Sun, 27 Apr 2025 23:05:37 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
To: ignace nyamagana butera <nyamsprod@gmail.com>
Cc: =?UTF-8?B?TcOhdMOpIEtvY3Npcw==?= <kocsismate90@gmail.com>,
 PHP Internals List <internals@lists.php.net>
References: <CAH5C8xUb1O20ZDrOQNC=ckFxHUUWSK7sw_njQQzFBd0qgQqoww@mail.gmail.com>
 <1BCB4144-231D-45EA-A914-98EE8F0F503A@automattic.com>
 <8E614C9C-BA85-45D8-9A4E-A30D69981C5D@automattic.com>
 <CAH5C8xV69pHnSKWJrVB8EQab7vPhcaXAwYezoG6z3Oj7ZkXBaQ@mail.gmail.com>
 <bc5472e39bc607e2c7accc9d2bd6f239@bastelstu.be>
 <CAH5C8xW_auVf+ig7odhTK8dVWwmXTg4ZVZN-0Fhh4SUBzrWxVw@mail.gmail.com>
 <8df04e01-deac-404b-beb7-cd982423db63@bastelstu.be>
 <CAH5C8xU0JcnmC2Hdd=Hj0CQUaL0-LN=1X8+5-eUbFH3ZMxCvBA@mail.gmail.com>
 <33427cd03035ef084245c44290b56a55@bastelstu.be>
 <CAH5C8xXwDO6Ui8pLmqoxEguURh97fAaL4CfLK-oitqC85N7+8w@mail.gmail.com>
 <0aa1eefc3941bdea0092e935074daa58@bastelstu.be>
 <CAH5C8xU+rnp4e5=CzqhEncRww6nhZ7x1s68NjWtu+HQMpoNZ8g@mail.gmail.com>
 <76d96ea8a78c6025128c0a4b01c94c0a@bastelstu.be>
 <CAOV5rgbYk7xZShs1933JR29NKr_MSCRqvkTdzn0Wpt4ejAC8TQ@mail.gmail.com>
 <99d8eacb-1058-44d2-b6e1-314846d59e54@bastelstu.be>
 <CAOV5rgaff1-5sbYTYg8jiVGXv_6WNY6i6BVwNYspPLHPAc40FA@mail.gmail.com>
Content-Language: en-US
In-Reply-To: <CAOV5rgaff1-5sbYTYg8jiVGXv_6WNY6i6BVwNYspPLHPAc40FA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 4/27/25 22:50, ignace nyamagana butera wrote:
> I understand that but then I fail to see the added value of the parse
> method vs the default constructor since from the RFC the only difference is
> that the parse named constructor should instead of throwing return null. If
> the parse method can still throw from a consumer POV it looses much of it's
> utility. If I really want that level of knowledge using the constructor
> should be the only way to go AFAIK.
Since the `$baseUri` is a known existing URI, I expect it to be always 
be valid, otherwise it would be a programming error. The (relative) $uri 
is the bit that comes from an untrusted source. Handling both cases by 
returning `null` would make the API much worse, since it is no longer 
clear which of the values is invalid.

Perhaps as a solution, it would make sense to change the signature to:

     (string $uri, ?self $baseUri = null)

instead to enforce that the $baseUri must be valid. This might also 
improve performance, by allowing to avoid repeatedly parsing the 
$baseUri, e.g. when bulk processing a number of relative links.

Best regards
Tim Düsterhus