Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Máté and Tim Why can't the Url::resolve method also expose the $errors parameter like the constructor and the parse static method ? As far as I understand it nothing prevents the API from exposing the errors during URI resolution which is a proxy method for the constructor call just like the parse named constructor ? On Wed, Apr 30, 2025 at 9:58 AM ignace nyamagana butera <nyamsprod@gmail.com> wrote: > Hi Máté and Tim > > I read the following in the RFC > > >Withers of Uri\WhatWg\Url follow the relevant “setter steps” that are > defined <https://url.spec.whatwg.org/#dom-url-protocol> > by WHATWG URL. > Unfortunately, these algorithms sometimes have surprising behavior where > modification fails silently, and the original values are kept. For example. > Even though this RFC acknowledges the fact that the WHATWG URL “setter > steps” have gotchas, it doesn't try to prevent them - as doing so would be > spec-incompliant. > > Reading the WHATWG URL specification and checking how > > - Chrome, > - Firefox > - and even https://github.com/TRowbotham/URL-Parser > > > behave I see that mutator either silently reject the invalid input on > setter or normalize them I was wondering if it still make sense to still > say that URL mutator can throws InvalldUrlException ? Since AFAIK only a > TypeError could actually be thrown if the wrong input is given, no > specially crafted string can make the spec throw unless I have overlooked > it. > > On Tue, Apr 29, 2025 at 8:55 PM Tim Düsterhus <tim@bastelstu..be> wrote: > >> Hi >> >> On 4/29/25 10:54, ignace nyamagana butera wrote: >> > I have one last question while reviewing my polyfill implementation. Is >> it >> > worth it adding a SensitiveParameter attribute on the argument of the >> > following methods ? >> > >> > - Uri\Rfc3986\Uri::withUserInfo >> > - Uri\WhatWg\Url::withPassword >> > >> > I'm fine with any answer ? Does it warrant a paragraph in the RFC ? >> That I >> > do not know but I feel the question may be raised ? >> >> Good catch. Since they may throw an exception for malformed inputs, they >> should have the attribute. Especially since folks might try to use >> special characters in passwords, which might need encoding. >> >> No paragraph in the RFC needed, but the attribute should be added to the >> “stub”. >> >> Best regards >> Tim Düsterhus >> >