Discussion on Ia16d8f86b1cb20 indicates that we want to go in the other
direction - MediaWiki shouldn't set X-Forwarded-Proto, rather the
reverse proxy (envoy in Wikimedia's case) should set it.
This follows-up cc241c2add.
Bug: T288848
Change-Id: Ifc5e9da9a02b45d9d1ad51c3e1389f9ac7325c86
$wgLocalHTTPProxy can be used to configure a reverse proxy
for requests to domains in $wgLocalVirtualHosts. The previous
implementation of using it as a proper HTTP proxy is no longer
supported and has been reverted out of REL1_37 (856da72363d1ba8bf).
It sets the hostname of the request as a "Host" header, scheme as
"X-Forwarded-Proto" and then sets the proxy's scheme, host and port as
those of the request.
Bug: T288848
Change-Id: Ibc3616f5ad925d464d937ab15461a88619c8b7a7
Ended up using
grep -Prl '\->setMethods\(' . | xargs sed -r -i 's/setMethods\(/onlyMethods\(/g'
special-casing setMethods( null ) -> onlyMethods( [] )
and then manual fix of failing test (from PS2 onwards).
Bug: T278010
Change-Id: I012dca7ae774bb430c1c44d50991ba0b633353f1
Guzzle is a vendor library included with MediaWiki, and it is
sometimes useful to directly use a GuzzleHttp\Client instance.
Add a function to HttpRequestFactory for this purpose.
Bug: T263816
Change-Id: I35f4b911676c7a58dfa5a8dd0d104125188dd62c
The headers passed to Guzzle via the Client constructor are termed
"conditional", meaning that headers in the Request override them. If you
set a "body" option containing a MultipartStream, it sets a default
Content-Type request header, overriding the one from the Client
constructor. So to send a multipart stream with a custom Content-Type,
it is necessary to pass headers to Guzzle in the Request object.
Change-Id: Ie7bfc548ce4211fbf3ec67e3913bbdd3482977c3
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
* 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
Currently GuzzleHttpRequest is not sending any cookies.
Furthermore, Guzzle expects its own format of CookieJar,
which is not compatible with CookieJar used by MediaWiki.
Solution is to add Guzzle Middleware that would obtain Cookie header
from MediaWiki CookieJar and add it to outgoing Guzzle requests.
Note: special handling of received cookies (Set-Cookie header
from the server) is unnecessary, this is not Guzzle-specific code
and is already done in MWHttpRequest::parseCookies().
Still, adding both a test of sending cookies and receiving cookies.
Bug: T245644
Change-Id: If69840e65d5671989cf15450964da3c691fd164a
The MWHttpRequest is implemented by the
CurlHttpRequest class and also the
GuzzleHttpRequest class. However, curl based rendering set
the CURLOPT_POST which implies that the 'Content-Type'
header defaults to 'application/x-www-form-urlencoded'.
To homgonize the functionality this patch mimics the
curl behaviour in Guzzle.
Bug: T232866
Change-Id: Id60a8de18e5f1e750a3bde23bd8b0deca4071165
assertSame() is guaranteed to never do any magic type conversion.
This can be critical when accidentially comparing empty strings (a
value PHP considers to be "falsy") to false, 0, 0.0, null, and such.
Change-Id: I2e2685c5992cae252f629a68ffe1a049f2e5ed1b
assertSame() is guaranteed to not do any type conversion. This can be
critical when acciden tially comparing, for example, 0 to 0.0.
Change-Id: Iffcc9bda69573623ba14af655dcd697d0fcce525
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
This also moves several tests out of HttpTest, so they are not lost when
the deprecated Http class is removed.
Bug: T222935
Change-Id: Ib4aac96ba1a978e8b6738ed446663afc3cc8c792
All methods got moved to HttpRequestFactory or MWHttpRequest or dropped.
I made the return value of the new HttpRequestFactory::request/get/post
methods null on error instead of false, so that when we drop PHP 7
support, we can use a "?string" return value. This could theoretically
change behavior of code that was switched from the old Http methods, but
probably won't. I kept the old behavior for the deprecated methods.
I changed the default value of $wgHTTPProxy from false to ''. This way
it should be usable directly without a trivial wrapper method. For the
benefit of anyone who might have set it to false in LocalSettings.php, I
also recommend casting to string just in case.
Http::$httpEngine is deprecated. Eventually it will be removed along
with the curl and PHP engines, leaving only the Guzlle engine.
I also added deprecation of MWHttpRequest::factory, which occurred in
1.31, to the release notes for 1.34. Now hopefully we can hard-deprecate
it in another couple of versions.
Bug: T214390
Change-Id: I2a316a758d793857f248bd251b90f5e9a6440e3a
Provide backward compatibility for callback functions in
GuzzleHttpRequest, which was missing in T202110, and restore
GuzzleHttpRequest as the default provided by HttpRequestFactory.
Bug: T212175
Depends-On: I4b45e79d35252d13f714f3271b87301ca515121a
Change-Id: I60d1a034b44874f6d24a04058db264eeb565f5e1
Create a GuzzleHttpRequest class using the external Guzzle
(docs.guzzlephp.org) library. This will be the new default request type,
but CurlHttpRequest and PhpHttpRequest remain available and accessible
via Http::$httpEngine.
Bug: T202110
Change-Id: Ie720be2628d7baf427b002847f103fd86ee4cff3
Depends-On: I143a6410d111e75f01dbbfd43f300e2e60247451
Prior to 3de744597e, it was possible to pass `null` for $options.
Restore that by setting the default type to be null, and explicitly
document that null is a supported value in the doc block.
Also update the signature of MWHttpRequestTester to match.
Change-Id: I74d586afa5527e0a30ea99f3989f4dd12fa9fea1
These tests apply to things that are not relevant to PHP code coverage,
such as testing presence of messages, JSON files, or the PHPUnit tests
themselves.
Using @coversNothing indicates that there is no code here to be covered,
and prevents warnings when using --strict-coverage mode (T152923).
Change-Id: Id89ee2c15a3ce3f10e34b13fb677cd1af75af9e6
* Complete coverage for Http::getProxy().
* Remove bogus @covers tag on data provider, and add the
relevant MWHttpRequest::getFinalUrl to the test instead.
* Convert test to use dataProvider and add missing test cases
to increase getFinalUrl() test coverage to 100%.
* Minor clean up in getFinalUrl to consistently use early-return
for all cases, not just for relative 'domain' and 'isset-host'
cases. Without this coverage actually couldn't reach 100% due
to the remainder of the empty else branch never being reached
(CRAP: "Redundant 'else' after 'return'")
Change-Id: I775d95965dc23a1e6c4c62ed84f9da64b6c72135
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I46261416f7603558dceb76ebe695a5cac274e417
* added integration tests. We probably don't want automated tests
to make external requests but these make manual testing more
convenient. Documented some oddities discovered by testing.
* made ::$status, ::proxySetup() and ::getHeaderList()
protected; they were not referenced in any gerrit-hosted extension
and they provide no useful functionality to external callers.
Similarly, marked ::read() and ::errorHandler() as internal
(these are used as callbacks so can't be protected)
* removed inheritance abuse in ::execute()
* documented ::execute() as returning a StatusValue (but
keep returning a Status for now)
* changed setCookie argument defaults to ones that make sense
* replaced MWException
* moved unit tests to the correct location
* fixed some code style issues
Change-Id: I5852fc75badc5d475ae30ec2c9376bde7024bd95
