Ideally we wouldn't have sent headers yet, but in some weird
code paths where we output stuff raw (like Export) we might
have already sent them.
All depends on when the failure happened.
Should silence all of the "headers already sent" being seen
from exports.
Change-Id: I12e0532e93d30b2255f73a9d0e017c73e30c3e28
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
The MWException::getPageTitle method is wrapping the page title
in the 'pagetitle' ($1 - sitename) message, but OutputPage does
this as well when outputing <title>.
OutputPage::prepareErrorPage takes the first parameter as page
title (unwrapped, appears in <h1>,) and the second optional one
is for <title>, which (if omitted, like before) results in
pagetitle being applied by OutputPage.
Now that we specify them separately, this also removes the
sitename from the <h1> on the page, which always looked weird.
It also fixes DBQueryError (extends MWException) where previously
no sitename was added, it just returns 'databaseerror' from
its DBQueryError::getPageTitle() method.
Change-Id: I85d65d89e72b4497a050f440524ff6f959518b88
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
One of the causes (if not the cause) of bug 56269 is if something
manages to throw an exception that makes it to MediaWiki::run's
last-resort exception catcher while having an open database transaction:
the transaction never gets committed or rolled back, so it gets
implicitly rolled back and a warning is raised.
The API has the opposite problem in bug 63145: it catches the exception
but then does the normal DB shutdown which *commits* the transaction.
This is certainly the Wrong Thing to do.
Ideally, neither of these would ever happen because any code using
transactions would have its own try-catch that would catch any
exception, rollback the transaction, and then rethrow the exception. But
it happens anyway, so let's have both of these last-resort exception
handlers do the rollback, and also log the exception so the throwing
code has a better chance of being properly fixed.
Bug: 56269
Bug: 63145
Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
