This effectively reverts ef26a5b07b (I245747d0b6fcdf0f6), which
added the pre-caching to implicity autoload additional classes used by
getRequestId(), per https://phabricator.wikimedia.org/T261260#6630577.
This has since been fixed by 5ab13a054 (Ia542ac7aab7b), which
simplified WebRequest::getRequestId to no longer involve other classes.
The impact of ef26a5b07b was that `$wgAllowExternalReqID` no
longer worked in production, because HeaderCallback is, and has to,
be called in Setup.php prior to loading LocalSettings.php, thus it
couldn't be set in time. This meant the `reqId` logged from MW went
back to the value of UNIQUE_ID or wfRandomString, not X-Request-Id.
Side effects:
* WikimediaDebug can't find XHGui profiles because
wmf-config/profiler.php sees `X-Request-Id`, whereas the JS code
that exported the value of `getRequestId` does not, thus they have
different IDs.
* Logstash search for a reqId no longer find messages correlating
with php-wmerrors (puppet php7-fatal-erorr.php), same issue as
XHGui.
* Logstash results from Varnish, ATS, or Apache don't correlate with
MW log messages, etc.
Bug: T273256
Change-Id: I3d5f440591c83d7f8c133e3e3a544175313bbd6b
Apparently PHP's autoloader doesn't work properly in a header
callback that's invoked after a fatal error.
Bug: T261260
Change-Id: Ia3711459d2230994f30cda094dc95d02a587e068
To make correlating MediaWiki logs and reverse proxy logs easier,
set the X-Request-Id header on responses. Ideally the header
would be set by the reverse proxy on the incoming request (see
e.g. T221976), but that is more complicated to set up consistently
and will be different for different MediaWiki setups; this patch
provides a simple fallback mechanism.
When the request itself had an X-Request-Id header (and
$wgAllowExternalReqID is set), this makes MediaWiki reflect that
header back; otherwise the value is a long random string.
Given that the header will be cached by reverse proxies, it is
not really a request ID (something unique to the request
that the header was sent in response to) as a "request group ID"
(shared by all requests which were served with the same cached
response), but we already had this semantic mismatch with the
wgRequestId JS variable, this patch just makes the ID easier
to log.
Bug: T201409
Change-Id: I9bca677b945ca3aa0e50d81bb468862efec54890
Avoid logging session cookies and other similar data, but leave
enough for correlating with other logs.
Change-Id: Ie2b622eb606605aed2b2fada1da040320bd27639
Install the backtrace collector very early, so that we can get the
backtrace even if headers were sent from LocalSettings.php.
Bug: T157392
Change-Id: I9bc732b34481c95afb5362e135a87bd4302498e2
