Page MenuHomePhabricator

wikidata.org handles GET MWAPI requests, but silently fails on POST
Open, NormalPublic

Description

Any MediawikiAPI GET requests works fine on both https://www.wikidata.org/w/api.php and https://wikidata.org/w/api.php, but POST requests only work with the www one. This creates a very difficult issue to debug -- everything works until at some point code tries to upload, at which point the API responds with a status=200 HTML (!) content of the main API help page.

I think POST requests to wikidata.org should result in some HTTP error with some text explaining the issue. For consistency with mwapi, MediaWiki-API-Error might also need to be set.

Event Timeline

Yurik created this task.Wed, Aug 7, 6:03 PM
Restricted Application added a project: Core Platform Team. · View Herald TranscriptWed, Aug 7, 6:03 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Yurik updated the task description. (Show Details)Wed, Aug 7, 6:23 PM
Yurik renamed this task from Wikidata breaks MW-API response format on (some?) errors to wikidata.org handles GET MWAPI requests, but silently redirects on POST.Wed, Aug 7, 8:49 PM
Yurik renamed this task from wikidata.org handles GET MWAPI requests, but silently redirects on POST to wikidata.org handles GET MWAPI requests, but silently fails on POST.
Yurik updated the task description. (Show Details)
Yurik added a project: Operations.
Yurik updated the task description. (Show Details)Wed, Aug 7, 8:57 PM
mobrovac triaged this task as Normal priority.Thu, Aug 8, 9:30 AM
Addshore moved this task from incoming to monitoring on the Wikidata board.Fri, Aug 9, 12:38 AM
Addshore added a subscriber: Addshore.
Anomie added a project: Traffic.

There's nothing to do with MediaWiki-API here, or with MediaWiki at all. Any request to wikidata.org is served a 301 redirect to the corresponding www.wikidata.org URI before it even reaches MediaWiki (probably at the Apache or Varnish level).

Apparently whatever client library you're using to make the requests is converting the POST to a GET when following the redirect (as allowed but not necessarily recommended by RFC 7231 § 6.4.2), which is why your POSTs return the response that api.php gives when no parameters are specified.

Ideally you shouldn't be using a non-canonical endpoint that redirects in the first place, particularly for POSTS. I'm going to punt this over to Traffic in case they want to consider changing the 301 to a 307 for such POSTs to avoid issues like this from clients like yours, but I wouldn't object if they decide to decline the task.

ema moved this task from Triage to Caching on the Traffic board.Wed, Aug 14, 12:45 PM