Page MenuHomePhabricator

Grace period for toolforge.org migration to tools exposing POST-based APIs?
Closed, ResolvedPublic

Description

Dear Toolforge admins,

I read that the permanent redirects from tools.wmflabs.org to *.toolforge.org (T234617) are going to be introduced this month (15th June). This is a problem for the openrefine-wikidata tool (T254169), which exposes an API where POST is used by clients. It is not possible to redirect POST requests, and therefore I anticipate that all queries made to the service via its old URL will fail. This is an API where it is normal to perform a POST request out of the blue, without any preliminary GET request.

The solution of course is that clients update the URL they query, but since the service is offered as a documented API (following public specifications), there is no list of such clients and no guarantee to update them all in time.

I therefore request your clemency in the migration (so, continuing to serve the service from tools.wmflabs.org), ideally of a few months if that is not too much to ask for. On my side, I will work to:

  • work with the W3C Community Group to devise a good mechanism in the specifications to ensure clients follow the change, for instance by adding a preliminary GET request before any session of POST requests, and publish a new draft of the specifications accordingly;
  • patch the historic client (OpenRefine) of this API to follow the agreed mechanism above.

Sorry for not bringing up this issue earlier, I did not realize that these POST requests would be an issue.
I suspect there might be other tools which expose POST-based APIs and which might suffer from the same issue.

Event Timeline

Pintoch created this task.Jun 1 2020, 4:01 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 1 2020, 4:01 PM
Jony added a subscriber: Jony.Jun 15 2020, 5:56 AM

After all it seems that OpenRefine actually follows HTTP redirects even for POST requests, which goes against the standards, but that is pretty lucky in this situation! So a countermeasure is not required, it seems. For users, updating the URL of the reconciliation service to the new one is still worth doing to avoid the cost of redirects (especially for auto-suggest or preview endpoints which are more time-sensitive).

Pintoch closed this task as Resolved.Jun 17 2020, 12:21 PM
Pintoch claimed this task.

Closing this since this does not seem to be an issue with the main client, OpenRefine. The endpoint is used by other clients but not to an extent that this should block the Toolforge migration.