On Sun, Jul 7, 2024, at 12:55, ignace nyamagana butera wrote: > Hi Máté, > > > Supporting IANA registered schemes is a valid request, and is > definitely useful. However, I think this feature is not strictly > required to have in the current RFC. > > True. Having a WHATWG compliant parser in PHP source code is a big +1 > from me I have nothing against that inclusion. > > > Based on your and others' feedback, it has now become clear for me > that parse_url() is still useful and ext/url needs quite some additional > capabilities until this function really becomes superfluous. > > `parse_url` can only be deprecated when a RFC3986 compliant parser is > added to php-src, hence why I insist in having that parser being present > too. > > I will also add that everything up to now in PHP uses RFC3986 as basis > for generating or representing URLs (cURL extension, streams, etc...). > Having the first and only OOP representation of an URL in the language > not following that same specification seems odd to me. It opens the door > to inconcistencies that will only be resolved once an equivalent RFC3986 > URL object made its way into the source code. > > On the public API side I would recommend the following: > > - if you are to strictly follow the WHATWG specification no URI > component can be null. They must all be strings. If we have to plan to > use the same object for RFC3986 compliant parser, then all components > should be nullable except for the path component which can never be null > as it is always present.
This isn't true. It's just that in the language it is specified in, any element can be null (i.e., no nullable types). It specifies what may be null here: URL Standard (whatwg.org) <https://url.spec.whatwg.org/#url-representation> — Rob
