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

Assigned To

None

Authored By

	• bzimport
	Sep 25 2011, 11:00 PM

Description

Author: jpatokal

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

http://www.mediawiki.org/wiki/Manual:Maxlag_parameter

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

$ curl -v 'http://en.wikipedia.org/w/api.php?action=query&meta=siteinfo&maxlag=-10'

About to connect() to en.wikipedia.org port 80 (#0)
Trying 208.80.152.2... connected
Connected to en.wikipedia.org (208.80.152.2) 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
Host: en.wikipedia.org
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:

https://github.com/jpatokal/mediawiki-gateway/issues/22#issuecomment-2191496

Version: 1.17.x
Severity: normal

Details

Reference: bz31156

Event Timeline

• bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:52 PM

• bzimport added a project: MediaWiki-Action-API.

• bzimport set Reference to bz31156.

• bzimport added a subscriber: Unknown Object (MLST).

• bzimport created this task.Sep 25 2011, 11:00 PM

I think maxlag giving 503 is only supposed to happen on the normal web interface (aka http://en.wikipedia.org/w/index.php?maxlag=-1 ) 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:

Is this fixed now?

http://en.wikipedia.org/wiki/api.php?action=view&maxlag=-1

gives a 503.

M8R-udfkkf wrote:

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

Maxlag errors returning 200 OK, not 503 as documentedClosed, DeclinedPublicActions

Description

Details

Event Timeline

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