mediawikicore.git - The collaborative editing software that runs Wikipedia.

	Commit message (Collapse)	Author	Age	Files	Lines
*	HeaderCallback: Remove pre-caching of WebRequest::getRequestId	Timo Tijhof	2021-03-10	1	-2/+0
\| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	This effectively reverts ef26a5b07b77bcce (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 ef26a5b07b77bcce 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
*	HeaderCallback: pre-cache request ID	Gergő Tisza	2020-11-18	1	-0/+2
\| \| \| \| \| \| \|	Follows up on Ia3711459d22309. Bug: T261260 Change-Id: I245747d0b6fcdf0f64d7aabe9972062472dc36da
*	Preload class used in HeaderCallback	Gergő Tisza	2020-10-01	1	-0/+7
\| \| \| \| \| \| \| \|	Apparently PHP's autoloader doesn't work properly in a header callback that's invoked after a fatal error. Bug: T261260 Change-Id: Ia3711459d2230994f30cda094dc95d02a587e068
*	Merge "HeaderCallback: Sanitize cookie values in debug logs"	jenkins-bot	2020-07-03	1	-1/+21
\|\
\| *	HeaderCallback: Sanitize cookie values in debug logs	Gergő Tisza	2020-06-28	1	-1/+21
\| \| \| \| \| \| \| \| \| \| \| \| \| \|	Avoid logging session cookies and other similar data, but leave enough for correlating with other logs. Change-Id: Ie2b622eb606605aed2b2fada1da040320bd27639
* \|	Set X-Request-Id on all web responses	Gergő Tisza	2020-06-30	1	-0/+6
\|/ \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \| \|	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
*	Add some @since tags to HeaderCallback	Reedy	2019-06-06	1	-0/+9
\| \| \| \|	Change-Id: I28053418d107f4a101aa7d8a2203c6864acd311f
*	Fix HeaderCallback failing on headers without a colon	Thiemo Kreuz	2019-02-19	1	-2/+6
\| \| \| \| \|	Bug: T216086 Change-Id: I3007a5bc238a5271cc3fe4da1844ff74efd58be0
*	Log a backtrace from the culprit location if headers were already sent	Tim Starling	2017-02-23	1	-0/+69
	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