Per my caller survey in the linked bug, it is hard to find a caller
which actually needs a long timeout, but many callers used the default
timeout without reviewing it. The default was increased from 300 to 900
as a quick hack to fix T226979, but that has now been fixed by overriding
the timeout in SwiftFileBackend specifically.
Reduce the default to 30 since that is a more reasonable value to use when
serving web requests. Since everything that previously used this default
was migrated to use HttpRequestFactory::createMultiClient(), the timeout
for them was already reduced from 900 to 25 with no apparent ill
effects. This cleanup change should have no production impact.
Bug: T245170
Change-Id: Id6029afa4e3f1c6551cd823c3b0def01afcdc571
* Add HttpRequestFactory::createMultiClient(), which returns a
MultiHttpClient with configured defaults applied. This is similar to
the recently-deprecated Http::createMultiClient().
* Introduce $wgHTTPMaxTimeout and $wgHTTPMaxConnectTimeout which, if set
to a lower value than their defaults of infinity, will limit the
applied HTTP timeouts, whether configured or passed on a per-request
basis. This is based on the frequently correct assumption that ops know
more about timeouts than developers.
* In case developers believe, after becoming aware of this new situation,
that they actually do know more about timeouts than ops, it is possible
to override the configured maximum by passing similarly named options
to HttpRequestFactory::createMultiClient() and
HttpRequestFactory::create().
* Apply modern standards to HttpRequestFactory by injecting a logger and
all configuration parameters used by its backends.
* As in Http, the new createMultiClient() will use a MediaWiki/1.35
User-Agent and the 'http' channel for logging.
* Document that no proxy will be used for createMultiClient().
Proxy config is weird and was previously a good reason to use
MultiHttpClient over HttpRequestFactory.
* Deprecate direct construction of MWHttpRequest without a timeout
parameter
Bug: T245170
Change-Id: I8252f6c854b98059f4916d5460ea71cf4b580149
That breaks on Wikimedia beta cluster (T217733):
Warning: Invalid argument: option: 6 in
vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 56
Warning: Invalid argument: option: 6 in
vendor/guzzlehttp/guzzle/src/Handler/CurlFactory.php on line 56
Warning: Invalid argument: function: not string, closure, or array in
vendor/guzzlehttp/guzzle/src/Handler/CurlMultiHandler.php on line 108
Fatal error: Uncaught exception 'ConfigException'
Failed to load configuration from etcd: cURL error 23: Failed writing
header
This reverts commit 1e048a08b5.
Bug: T202352
Bug: T217733
Change-Id: I2384355043896128d3f191941e8da00fdc62361e
Convert MultiHttpClient to use the Guzzle library.
Guzzle includes built-in support for concurrency, and automatic
fallback to php streams if curl is unavailable.
Bug: T202352
Change-Id: I703af901f9da33d20b5e0989941f3f7fd6609298
The name of the test class and method as well as the @covers tags already
explain well enough which code a test is testing. Repeating this does not
provide additional information.
Change-Id: Ieec4ec131e5925d11704a11e1df46bc00c9fad9b
If the curl extension is not available, fall back to the existing
HttpRequestFactory and associated classes. Also added related phpunit tests.
Bug: T139169
Change-Id: I2f9d4acbb491bce28d7105e124c5cee7e16e86d7
