Not very good.

Now we have to mung two different layers of code together, to treat what should be API status but is being thrown as a network transport error. IMHO a poor design choice.

For example in my code, using Python urllib, it will disable the maxlag - backoff, seeing network transients and retrying very aggressively. To fix it, I have to add code at transport to catch the exception, turn it back into a "normal" API response, and return it. (I certainly can do this, but what I'm doing is patching over what is basically a bad response.)

best regards Robert

On Thu, Jul 16, 2009 at 2:39 AM, Carl (CBM)cbm.wikipedia@gmail.com wrote:

On Wed, Jul 15, 2009 at 5:30 PM, Roan Kattouwroan.kattouw@gmail.com wrote:

...

As of r52190 [1], API maxlag errors (the kind of error you get when you set &maxlag=2 and the maximum slave lag is higher than two seconds) return a HTTP 503 status code rather than a 200, for consistency with index.php (which does the same thing). The text of the response has not changed:

<api>  <error code="maxlag" info="Waiting for 10.0.6.38: 1 seconds lagged" /> </api>

If this is a 503 error, can't we set an HTTP header with the retry delay? Otherwise this adds yet another complexity to error handling. Index.php sets "Retry-After" and "X-Database-Lag" headers when maxlag is exceeded, via wfMaxlagError().

• Carl

---

Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

On Thu, Jul 16, 2009 at 04:40, Brad Jorschb-jorsch@northwestern.edu wrote:

On Wed, Jul 15, 2009 at 11:30:40PM +0200, Roan Kattouw wrote:

...

As of r52190 [1], API maxlag errors (the kind of error you get when you set &maxlag=2 and the maximum slave lag is higher than two seconds) return a HTTP 503 status code rather than a 200, for consistency with index.php (which does the same thing).

I agree with the others, this change should be reverted, as it is an arbitrary breaking change that makes things more difficult for API clients for consistency with something that is not really related.

index.php returns an HTTP 503 error because it speaks HTTP, and that's how you return errors in HTTP. But the API doesn't speak HTTP, it just uses HTTP as a ''transport layer'' and reports its errors using its own protocol. This change raises maxlag from an API-level error (where it belongs) to a transport-level error; it's the same as if we would have index.php return an ICMP error for maxlag.

...

Be aware that some client libraries may treat the 503 return code differently, which is why this could be a breaking change.

That's an understatement. Any logically-coded client library that bothers to check for errors will probably work something like this:

$response = send_http_request($uri, $postdata);  if ($response->is_http_error()) {      // Handle error      return null;  }

$result = parse_api_response($response->get_content());  if ($result == null) {      // Handle "unparsable response" error      return null;  }

// Any special API error logging/handling here

return $result;

As a result of r52190, that must become rather more complicated:

$response = send_http_request($uri, $postdata);

if ($response->http_status_code() == 503) {      // Maybe a maxlag error? Or maybe a real HTTP error, in which case      // parse_api_response() should fail?      $result = parse_api_response($response->get_content());      if ($result != null) {          // Any maxlag-specific special error logging/handling here          return $result;      }  }

if ($response->is_http_error()) {      // Handle error      return null;  }

$result = parse_api_response($response->get_content());  if ($result == null) {      // Handle "unparsable response" error      return null;  }

// Any special API error logging/handling here

return $result;

---

Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

I don't agree with your notion at all. max-lag should be handled outside the normal API system, and should be returned as 503. The nevessary headers are allready there, so your argument that you would need to parse the api-response twice is just wrong; Following pseudo code would be how maxlag should be handled:

function handle_response() { if status == 503 sleep( get_header_value( "Retry-After" ) ) http_post( this->post, this->handle_response ) return endif

parse_api() blablabla() }

I ask roan to undo the undo and let it be using 503 instead of 200, as 200 makes it more difficult to handle (would need to search for certain headers at each call and make string matching) this error in the correct way (in that the api should be fully bypassed)

On Sat, Jul 18, 2009 at 11:39, Russell Blaurussblau@imapmail.org wrote:

Carl Fürstenberg wrote on Friday, July 17, 2009 5:19 PM:

...

I don't agree with your notion at all. max-lag should be handled outside the normal API system, and should be returned as 503. The nevessary headers are allready there, so your argument that you would need to  parse the api-response twice is just wrong; Following pseudo code would be how maxlag should be handled:

function handle_response() { if status == 503   sleep( get_header_value( "Retry-After" ) )   http_post( this->post, this->handle_response )   return endif

parse_api() blablabla() }

Your argument assumes that all HTTP 503 errors are caused by maxlag, but this is not necessarily the case. http://www.mediawiki.org/wiki/Manual:Maxlag_parameter. If the 503 is caused by a squid timeout, your pseudocode will fail.  Further the response body might or might not be a valid api response on a 503; if it were a maxlag issue, it would be an api response inside the HTML body, but if it were a squid timeout it would just be an HTML message not containing an api response.  So I think Roan's decision was correct.

Russ

---

Mediawiki-api mailing list Mediawiki-api@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-api

The response body is irrelevant when a 503 is returned, you should use up to the three headers available instead of parsing the body.