It's now deprecated to use the individual error printing functions in
MWException or to override them. Printing MWException now works the
same as any other exception, and happens in MWExceptionRenderer.
It's still allowed to override MWException::report() to replace the
entire error page, for example in ErrorPageError.
Bug: T353444
Change-Id: I66d896f6f229b90e6ba9949311b56a6b6ab3da3d
createMock() does the same, but is much easier to read.
A small difference is that some of the replacements made in this
patch didn't use disableOriginalConstructor() before. In case this
was relevant we should see the respective test fail. If not we can
save some CPU cycles and skip these constructors.
Change-Id: Ib98fb06e0fe753b7a53cb087a47e1159515a8ad5
Single use method in both BadTitleErrorTest and ThrottledErrorTest,
merge into only place that needs it
Change-Id: I1a5c2ed2ac76ae821758d50b7d6378acb98af861
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
This patch fixes all PHPUnit 8 compat issues in the DBless suite, aside
from assertArraySubset.
Bug: T192167
Change-Id: Iea782386509b9e579f06d63687669e14bc437fad
It's annoying and pointless. Instead, have MWException write them to
standard output where we can catch them with ob_start().
Bug: T170028
Bug: T170029
Change-Id: Icd99c1c39d4a30d78c511d33948ef639e1b92455
ThrottledError currently returns a 503, which in turn results into
badly-written spambots occasionally flooding our 5xx logs and graphs.
There is no reason, however, for ThrottledError to return a 5xx in the
first place: it's a user-generated error (user hitting a rate limit and
being throttled), not a server error. 5xx error codes in general have
many other implications, such as frontend caches treating this as a
backend failure and potentially retrying the same request, so they are
unsuitable and undesirable for the ThrottledError exception.
RFC 6585 (April 2012, updates: 2616) has added a special 4xx code
specifically for rate-limiting, 429 Too Many Requests. As the
description of that code matches exactly what ThrottledError was meant
for, switch it to using 429 instead.
Note that there is a chance 429 might be mistreated and not showed by
older or badly-written user agents as it's fairly new and not part of
RFC 2616, the original HTTP/1.1 spec. However, the last paragraph of
section 6.1.1 of RFC 2616, specifically covers the issue of UAs &
unknown status codes: it dictates that applications MUST understand the
class of any status code and treat them as the "x00 status code of that
class" (here: 400), MUST NOT be cached, and "SHOULD present to the user
the entity returned with the response, since that entity is likely to
include human-readable information which will explain the unusual
status".
Change-Id: I46335a76096ec800ee8ce5471bacffd41d2dc4f6
- Added spaces after if/foreach/catch
- Added new line before end of file
- Added or removed spaces before/after parenthesis, comma
- Added spaces around string concat
Change-Id: I0590070f1b3542108e242730e8d9a3ba9831e94f
