Page MenuHomePhabricator

Maxlag errors returning 200 OK, not 503 as documented
Closed, DeclinedPublic


Author: jpatokal

The documentation for maxlag states that any errors should be returned with a 503 HTTP response code:

However, on the version of MW running on the English Wikipedia (1.17wmf1), the error comes back as 200 OK instead:

$ curl -v ''

  • About to connect() to port 80 (#0)
  • Trying connected
  • Connected to ( port 80 (#0)

GET /w/api.php?action=query&meta=siteinfo&maxlag=-10 HTTP/1.1
User-Agent: curl/7.19.7 (universal-apple-darwin10.0) libcurl/7.19.7 OpenSSL/0.9.8r zlib/1.2.3
Accept: */*

  • HTTP 1.0, assume close after body

< HTTP/1.0 200 OK
< Date: Sun, 25 Sep 2011 22:58:35 GMT
< Server: Apache
< Cache-Control: private
< Retry-After: 5
< X-Database-Lag: 0
< MediaWiki-API-Error: maxlag

Bug or feature? See also:

Version: 1.17.x
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:52 PM
bzimport set Reference to bz31156.
bzimport added a subscriber: Unknown Object (MLST).

I think maxlag giving 503 is only supposed to happen on the normal web interface (aka ) not the api (because errors are kind of handled in the api at the response level, not at the http protocol level) but I am unsure.

503s for maxlag in api.php were implemented at some point (in r52190) but reverted quickly (r53353) because of backwards compatibility concerns. See the discussion on those revisions for more background.

The manual page documents the 200 behavior now, thanks to this bug :)

M8R-udfkkf wrote:

Nevermind...the api still gives 200. (Above is not api request...silly me)