Actually, `->getBody()` returns a stream interface and in order to
get the body's content, just call `->getContent()` which will return
the response's body content in string format.
Change-Id: I9527c8a29c8da2342c8ac958c4e7bb6ba12fd613
Should be expected, and then actual
Switched some assertEquals to assertSame to fix failing
phpcs sniffs
Change-Id: I7257c5afacd22fed78a58f3cc918b721ac11a46d
This is a follow up to a previous fix in
4079d328e7 which used parse_url()==false
as an indirect test to see if `new Uri()` would throw. Avoid the
indirection and use a try/catch instead to be more robust against
fixes in the Uri library and/or the parse_url() implementation.
Bug: T256831
Bug: T261344
Change-Id: Ia52c5b2c77a4481afd82b468c2f7fb3c05996a91
Add the port to the 'REQUEST_URI' index to ensure the stubbed
port is properly returned.
Stubbing $_SERVER['SERVER_PORT'] directly apparently does not
work because WebRequest::getGlobalRequestURL() does not ask for
the port from that index.
Follow-up: Ib829afc7b33419b01e69ababa147d33b30c0fbcb
Bug: T259094
Change-Id: Iff8fab7b7eeb4c3f44072b83dc92c6dd895841c3
All titles that contain a colon followed by a number cannot, currently,
be accessed via the Rest endpoint.
For example https://en.wikipedia.org/wiki/3:33 is a valid title/article
on English Wikipedia and can be accessed there the index/api.php entry
points. But the rest endpoint will fatal:
https://en.wikipedia.org/w/rest.php/v1/page/3:33/history
The exception is thrown in Uri constructor of GuzzleHttp library
if parse_url() failed to parse the request URL. But parse_url() has
an open bug of failing to parse URLs that contain the above pattern.
The function returns false in such cases, (it previously raised warning
see I2715607);
To make our titles with this pattern accessible, we have to forestall
this exception.
Bug: T256831
Change-Id: Ib829afc7b33419b01e69ababa147d33b30c0fbcb
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
apache_request_headers() is a vendor-specific function - it got used
when present and alternative code paths were exercised otherwise.
These preserved certain "special" headers, e.g. Content-Type, only
inconsistently.
The function getallheaders() is an alias[1] for apache_request_headers()
on systems where the latter is present. Alternatively, there is a
polyfill (ralouphie/getallheaders) which is already installed in
mediawiki-vendor[2] (by virtue of guzzle).
Using getallheaders() exclusively, will make sure these "special"
headers are consistently available alongside their "regular"[3] peers
and helps MediaWiki code focus on its domain.
The dependency to ralouphie/getallheaders is made explicit in the same
version in which it is currently locked in mediawiki-vendor[4].
This surfaced because the deprecation warning for API POST requests
without a Content-Type header, introduced in bba1a0f, appeared in my
development system (somewhat dated addshore/mediawiki-docker-dev/) even
though the client did a fine job.
Interesting implementation detail: While WebRequest keeps track of
headers using keys in all upper case, REST RequestFromGlobals does so in
all lower case - but both use retrieval logic complementary to their
respective approach however. In case of REST RequestFromGlobals this is
encapsulated inside of HeaderContainer (setting and retrieving), while
WebRequest does all of this by itself. Cf. [5] and [6]
[1]: https://www.php.net/manual/en/function.getallheaders.php
[2]: https://github.com/wikimedia/mediawiki-vendor/tree/8f2967d/ralouphie/getallheaders
[3]: https://www.php.net/manual/en/reserved.variables.server.php#110763
[4]: https://github.com/wikimedia/mediawiki-vendor/blob/8f2967d/composer.lock#L3250
[5]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
[6]: https://www.php.net/manual/en/function.apache-request-headers.php#124236
Bug: T245535
Change-Id: Iba52f152e15928473b729a2588c2462e76e85634
