Hi Michał, Thanks for your comments. You made me realise that the RFC missed information on a crucial part which is the new CURLOPT_CURLU option that tells curl to use the CurlUrl object instead of the "standard" CURLOPT_URL option. I just added some information on it in the RFC.
The purpose of the CurlUrl class is to be able to build/see/modify an URL as it is seen by libcurl before/after passing it to your CurlHandle. It is not meant to be used alone as a representation of an URL. For example, you may want to do some checks to make sure that the URL you gave to your CurlHandle is well formatted and that the host or any other parts are what you want them to be, and that it was not something else because of some differences on how the URL was parsed. Or you may want to add/delete/overwrite some parts to sanitize your URL. That's why you have those setters/getters. This class is definitively not there to replace PSR-7 UriInterface. I can imagine some Guzzle or other implementation to build a CurlUrl handle from a UriInterface before giving it to curl. So this RFC is really targeted to users of curl_* functions. Le lun. 27 juin 2022, à 02 h 29, Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> a écrit : > Hi Pierrick > > śr., 22 cze 2022 o 06:38 Pierrick Charron <pierr...@php.net> napisał(a): > >> Hi, >> >> Following our discussions we had on the subject of the new Curl URL API, >> and other curl improvements. I decided to only focus on adding the new >> Curl >> URL API and put aside all other improvements. Here is the RFC that >> reflects >> our current conversations. >> >> https://wiki.php.net/rfc/curl-url-api > > > TBH I have a problem with the proposed Curl* classes. > IMO they present a mix of responsibilities that I don't like. > > CurlUrl is for me is a mix of Url/Uri object properties well known from > other userland implementations like the PSR one > with Uri specific like the host, scheme, port, path, query, fragment, etc. > but on the other hand, we have flags and options which > purpose is to pass Curl specific things but in IMO wrong place instead > (for instance Guzzle use separate argument in all methods for options and > flags. > Secondly, it has some default logic like `setScheme` allows to put a > scheme but requires the supported one, with an exception that you can > ignore support checking by a flag - IMO this logic belongs to its consumer > logic and is not part of URL class logic and the `setPort` like above. > Next thing is that it again has all the getters and setters and is not > immutable. Why can't it be a simple constructor with read-only properties, > no getters, no setters? Maybe I miss some discussion about why here. > > > The same goes for CurlException which looks like is an exception for > handling some encoding of Url and not exactly to the Url properties itself. > > But with all that said, if the target audience is only a user of low lever > `curl_*` functions rather than users of higher abstraction libraries like > Guzzle or Httplug then, I guess I don't care that much. > I'm only afraid that such a mix of responsibilities can lead to bad habits > when it gets to the separation of concerns by developers who get used to it > and won' see the problem as I do. > > Cheers, > Michał Marcin Brzuchalski >
