Hi Maté, Fantastic RFC :)
Le dim. 7 juil. 2024 à 11:17, Máté Kocsis <kocsismat...@gmail.com> a écrit : > Hi Ignace, > > As far as I understand it, if this RFC were to pass as is it will model >> PHP URLs to the WHATWG specification. While this specification is >> getting a lot of traction lately I believe it will restrict URL usage in >> PHP instead of making developer life easier. While PHP started as a >> "web" language it is first and foremost a server side general purpose >> language. The WHATWG spec on the other hand is created by browsers >> vendors and is geared toward browsers (client side) and because of >> browsers history it restricts by design a lot of what PHP developers can >> currently do using `parse_url`. In my view the `Url` class in >> PHP should allow dealing with any IANA registered scheme, which is not >> the case for the WHATWG specification. > > > 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. > Anyone we needs to support features that are not offered by the WHATWG > standard can still rely on parse_url(). > If I may, parse_url is showing its age and issues like https://github.com/php/php-src/issues/12703 make it unreliable. We need an escape plan from it. FYI, we're discussing whether a Uri component should make it in Symfony precisely to work around parse_url's issues in https://github.com/php/php-src/issues/12703 Your RFC would be the perfect answer to this discussion but IRI would need to be part of it. I agree with everything Ignace said. Supporting RFC3986 from day-1 would be absolutely great! Note that we use parse_url for http-URLs, but also to parse DSNs like redis://localhost and the likes. > And of course, we can (and should) add > support for other standards later. If we wanted to do all these in the same > RFC, then the scope of the RFC would become way too large IMO. That's why I > opt for incremental improvements. > > Besides, I fail to see why a WHATWG compliant parser wouldn't be useful in > PHP: > yes, PHP is server side, but it still interacts with browsers very > heavily. Among other > use-cases I cannot yet image, the major one is most likely validating > user-supplied URLs > for opening in the browser. As far as I see the situation, currently there > is no acceptably > reliable possibility to decide whether a URL can be opened in browsers or > not. > > - 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. >> > > Thank you for the historical context! > > 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. That's why it now seems to me that the > behavior of > parse_url() could be leveraged in ext/url so that it would work with a > Url/Url class (e.g. > we had a PhpUrlParser class extending the Url/UrlParser, or a > Url\Url::fromPhpParser() > method, depending on which object model we choose. Of course the names are > TBD). > > 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. >> > > My WIP implementation still uses nullable properties and return types. I > only changed those > when I wrote the RFC. Since I see that PSR-7 compatibility is very low > prio for everyone > involved in the discussion, then I think making these types nullable is > fine. It was neither my > top prio, but somewhere I had to start the object design, so I went with > this. > > Again, thank you for your constructive criticism. > > Regards, > Máté >
