Last modified: 2008-10-21 00:11:09 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 10359 - Machine detectable signals about errors when GET/POST to WP
Machine detectable signals about errors when GET/POST to WP
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-24 20:23 UTC by Carl Fürstenberg
Modified: 2008-10-21 00:11 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Carl Fürstenberg 2007-06-24 20:23:17 UTC
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.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-24 23:15:25 UTC
Are there any appropriate HTTP response codes or headers, for instance?  Exactly what things do you want data for (cf. bug 2585)?
Comment 2 Carl Fürstenberg 2007-06-24 23:36:30 UTC
(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.
Comment 3 Roan Kattouw 2007-06-25 13:06:12 UTC
(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


Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-06-25 17:00:17 UTC
It doesn't allow actually editing pages, however, as he says.
Comment 5 Rob Church 2007-06-25 17:06:03 UTC
(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.
Comment 6 Chad H. 2008-10-21 00:11:09 UTC
API handles edits now, can mark this as fixed.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links