Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114039
MIME-Version: 1.0
References: <CAJSGLVNjkr4GErN6F7ANezJX5K19pQTM_ufMrXTT+UjUP4U2-w@mail.gmail.com>
In-Reply-To: <CAJSGLVNjkr4GErN6F7ANezJX5K19pQTM_ufMrXTT+UjUP4U2-w@mail.gmail.com>
Date: Mon, 12 Apr 2021 17:02:13 +0200
Message-ID: <CAF+90c-Dz1Cke5-NbJwCoZRvDkbJYO5DW4WEacBLbTOFKs7BgA@mail.gmail.com>
To: Michael Maroszek <paresy@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076ef8905bfc7cd01"
Subject: Re: [PHP-DEV] add php.ini entry to set default user_agent for curl
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000076ef8905bfc7cd01
Content-Type: text/plain; charset="UTF-8"

On Thu, Apr 8, 2021 at 2:41 PM Michael Maroszek <paresy@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

--00000000000076ef8905bfc7cd01--