TL;DR: Gadgets should use HTTP POST for purge/rollback/markpatrolled
Some gadgets still use HTTP GET for page purge requests.
In order to better facilitate multi-datacenter traffic routing  and to
better comply with web standards ,
these types of requests should use POST instead. GET is considered, by
specification, to be a "safe method".
Since purge requests perform database writes and potentially significant
rendering updates, they should use a
state-changing HTTP method. Also, achieving of our multi-datacenter goal as
planned involves leveraging safe
HTTP methods to route request to either the closest or the primary
datacenter for optimal performance.
Most of such requests to MediaWiki already require POST, but "purge" is one
of the exceptions. There is no
compelling reason for this to be exceptional, however. Exposing a URL
parameter that does database writes,
reparsing, and cache updates simply by following a link (especial with no
CSRF token) encourages bad practice
(having links that bypass cache) and the risk of performance problems if
such a link becomes popular.
Rollback requests should also use HTTP POST given that it results in a page
edit. The database operations are
far more complex than purge, so in a multi-datacenter system, such requests
(if using HTTP GET) could have much worse performance depending on the
client's location (even if very close to a datacenter). Ideally, reversion
tools would use the
API for rollback, instead of index.php.
The markpatrolled action, like rollback, also involves a GET request with a
MediaWiki provides already uses the API with POST, but users without
HTTP GET. The Gadgets should be converted to POST.
Purge, rollback, and markpatrolled support both POST and GET right now.
Gadgets still using GET for these actions
should be converted to use POST instead.
There is a task at T135170  for MediaWiki to require POST for purge
Also see T88044  for the same requirement for rollback requests.
Yaron Koren has proposed to reopen the "Unacceptable behavior" section
His perspective and mine are given on the talk page.
* He disagrees with how "marginalized and otherwise underrepresented
groups" and "encouraged" are handled in the original text.
* I support the current text and process, and have explained why on the
Every once in a while we see very hard to reproduce errors in the console
that we're not sure how often are actually happening, and that makes us
think that there may be other errors happening that we're not coming across
(or other people savvy enough to open the console and post a bug).
There are open source projects like sentry we could inspect and adapt a
client library for our purposes and log to EventLogging or somewhere else (
With the release of MediaWiki 1.27, the lifetime of MediaWiki version
1.25.x has come to an end.
Users still using MediaWiki 1.25.x are advised to upgrade to version
1.27.0, the latest stable and
MediaWiki announcements mailing list
To unsubscribe, go to:
With Wikimania and associated summer travel, this is going to be a rough
week to get everyone together at our usual time for the weekly
ArchCom-RFC IRC office hour:
There are a couple of RFCs that might make good short-term choices:
- T137926 - Require 'curl' PHP extension for MediaWiki
James filed this a couple of weeks ago as a "μRfC". The hope is
to enable greater use of MultiHttpClient.
- T136866 - Improve the per-programming-language listings for our
Quiddity plans to expand this documentation in the coming quarter.
A clearer idea about the status quo would help us guide developers
about which languages we hope to attract new development in.
However, we would welcome suggestions for others. Please comment here:
If nothing else, we can use this week's meeting as a triage discussion.
p.s. Updates continue on Architecture_committee/Status: