Page MenuHomePhabricator

Machine detectable signals about errors when GET/POST to WP
Closed, ResolvedPublic

Description

I request a system, that includes machine readable data about server/client error in a GET/POST request to the server, for example lost session notice.


Version: unspecified
Severity: enhancement

Details

Reference
bz10359

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:51 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz10359.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Are there any appropriate HTTP response codes or headers, for instance? Exactly what things do you want data for (cf. bug 2585)?

(In reply to comment #1)

Are there any appropriate HTTP response codes or headers, for instance?
Exactly what things do you want data for (cf. bug 2585)?

That's a tricky question. If a status number should be sent, then perhaps it should be 409. But more important would be a way to easily grab data about the current state of the session, if an edit succeeded or not, if the page existed or not etc... "Machines" still need parse the web pages, until the API handles edits.

(In reply to comment #2)

"Machines" still need parse the web pages, until the API handles
edits.

The API can already list information about pages, like whatlinkshere, whattranscludeshere, allpages, recentchanges, and much more. For a complete overview, see [[mw:API]] and http://www.mediawiki.org/w/api.php

ayg wrote:

It doesn't allow actually editing pages, however, as he says.

robchur wrote:

(In reply to comment #4)

It doesn't allow actually editing pages, however, as he says.

Correct, but that's a known issue. The API is intended to take over as the main interface for scripts, bots and other like applications, and will have machine-readable feedback.

We've had problems in the past when sending status codes with content that's intended for the user, so we need to be a bit careful about what we inject into the output.

The bug poster has also not provided any specific information on what he wants to happen under what circumstances, which makes coming up with an actual implementation compromise somewhat difficult.

API handles edits now, can mark this as fixed.