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

From:	Ignace Nyamagana Butera	Date:	Wed, 19 Mar 2025 21:18:24 +0000
Subject:	Re: [RFC] [Discussion] Add WHATWG compliant URL parsing API
References:	1 2 3 4 5 6 7 8 9 10 11 12	Groups:	php.internals
Request:	Send a blank email to [email protected] to get a copy of this message

On 17/03/2025 20:58, Máté Kocsis wrote:
Hi Ignace,

    1) around Uri\UninitializedUriException If I look at the
    behaviour of
    DatetimeImmutable in the same scenario or a Userland object
    instead of
    throwing an exception an error is thrown

    see:

    - https://3v4l.org/d4VrY
    - https://3v4l.org/Wn7En

    Shouldn't the URI feature follow the same path for consistency ?
    Instead
    of throwing an exception it should throw an Error on uninitialized
    issue
    at least.


Yes, you are right! Uri\UninitializedUriException should extend an Error indeed,
since people shouldn't try to catch it either.


    2) around Normalization. In case of query normalization, sorting the
    query string is not mention does it means that with the current
    feature

    http://example.com?foo=bar&foo=rab`
    <http://example.com?foo=bar&foo=rab>
    is different from
    http://example.com?foo=rab&foo=bar`
    <http://example.com?foo=rab&foo=bar>


Yes, that's the case, this feature is not implemented. As far as I see though, it's better
not to change the order of query parameters, especially the order of duplicated
parameters in order not to accidentally change the intended meaning of the query string.
What's your stance here?

Máté


Hi Maté,


Thanks for the clarifications, I ask for the latter because I am trying to create a polyfill using league/uri-interfaces so

my questions come essentially from me trying to create the correct polyfill to better understand the new class (specifically,

the RFC3986 Uri). You can find the ongoing work here if you want to see

https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php

While implementing the polyfill I am finding easier DX wise to make the constructor private and use instead named constructors for instantiation. I would be in favor of

Uri::parse and Uri::tryParse like it is done currently with Enum and the from and tryfrom named constructors.

My reasoning is as follow:

 there's no right way or wrong way to instantiate an URI there are only contexts. While the parse method is all about parsing a string, one could legitimately use other named constructors like Uri::fromComponents which would take for instance the result of parse_url to build a new URI. This can become handy in the case of RFC3986 URI if you need to create an new URI not related to the http scheme and that do not use all the components like the email, data or FTP schemes.

 By allowing creating URI based on their respective components value you make it easier for dev to use the class. Also this means that if we want to have a balance API then a toComponents method should come hand in hand with the named constructor.

I would understand if that idea to add both components related methods is rejected, they could be implemented on userland, but the main point was to prove that from the VO or the developer POV in absence of a clearly defined instantiation process, having a traditional constructor fails to convey all the different way to create an URI.