Hi Nikita, sure! We are embedding PHP through SAPI to allow our users interaction through PHP scripts. That allows them to automate a lot of things and one of them is doing web requests. For our new version we wanted to set the user-agent, to properly recognize/categorize requests on our infrastructure and where they are coming from. Therefore we liked the idea of doing it "globally" via a php.ini switch. This way we found the inconsistency between file_get_contents et al. and cURL and the missing possibility to define a default user agent for cURL. (I am aware that anyone can override the user-agent in userspace)
If you prefer to reuse the already available user_agent ini entry i will gladly update my PR. Doing the patch was quick. Making good tests took time. I know that my use case might not represent the majority of PHP users, therefore i tried to argue in direction of consistency instead of my rather minor use case. I hope that it helps to understand my motivation. Michael Am Mo., 12. Apr. 2021 um 17:02 Uhr schrieb Nikita Popov < nikita....@gmail.com>: > On Thu, Apr 8, 2021 at 2:41 PM Michael Maroszek <par...@gmail.com> wrote: > >> Dear Internals, >> I'd like to suggest a new enhancement for 8.1 as outlined in the title. >> >> The initial pull request is here: >> https://github.com/php/php-src/pull/6834/files >> >> --- Details: >> Since quite a while PHP offers a dedicated user_agent php.ini entry, but >> it >> affects only all internal implementations like file_get_contents. cURL has >> no default and you need to modify CURLOPT_USERAGENT in the code and for >> the >> SoapClient there is a parameter 'user-agent' in the constructor which can >> be set. >> >> Therefore I'd like to introduce an equal entry for curl.user_agent which >> would set a default user_agent when making curl requests. Of course you >> can >> override it with CURLOPT_USERAGENT if required. (I can implement the same >> for SoapClient, if requested) >> >> --- Alternative: >> I could also use the default user_agent entry, but I wasn't sure what the >> best practise is and went for the more "local" approach for the initial >> implementation. >> >> --- Bigger picture: >> When the preferred solution is to use the default user_agent, we could >> also >> try to determine more places where i could send the default user_agent to >> give this php.ini entry a more consistent feeling. >> >> Thanks for your consideration, >> Michael >> > > Could you please describe what your use case for this change is? > > I'm generally not a fan of adding more ini settings (aka global state) > without a strong motivation, and it's not immediately obvious what that > motivation is in this case. This seems useful if you have both a) one user > agent you want to use for everything and b) a lot of heterogeneous code > that doesn't use any common abstraction, which seems like a rather odd > situation to be in. > > Regards, > Nikita >
