Page MenuHomePhabricator

Mobile-html switchover to REST API (from RESTBase) should account for http 400 response for non-wikitext content models
Open, LowPublic


In T313265#8653252, we discovered a potential blocker for switching over mobile-html from RESTBase to the REST API.

Right now, apps "render" non-wikitext content models like "javascript" improperly since the RESTBase-Parsoid combo treats non-wikitext content models as wikitext and generates some output for those content models. The output may not necessarily be what is desired, but at least for some content models (like JS and CSS), the output may be mostly correct which is why this may not have noticed in the iOS and Android apps so far (combined with the fact that most folks will probably not look at these other content-models in the apps).

But, the REST API has a harder fail when requested to render non-wikitext content models. It returns a HTTP 400 (see T324711). So, this means when the mobile-html services switch from RESTBase to the REST API, all requests for these non-wikitext pages will now fail or render some error message in the iOS and Android apps.

So, before switchover, some adaptation solution would need to be devised to deal with this. There could also be an argument to be made for the REST API to provide an endpoint that transparently falls back to non-Parsoid rendering for these content-models (new endpoint or query param to an existing endpoint or a http header or whatever seems appropriate). Alternatively, mobile-html will need to handle this. OR, the apps will need to handle this (if they don't intend to handle non-wikitext content models, by displaying an appropriate error message).

This task is likely a blocker to switchver

Event Timeline

Are there ways we could provide a simple fallback when non-wikitext content models are accessed through PCS as a stop gap?

If all non wikitext content models aren't going to work it does have impact on content adjacent spaces like template styles and lua modules. But most of those use cases for non-wikitext content models could likely be solved with just serving the raw wikitext. As a stop gap I think that would suffice until we can fine a better solution.

daniel triaged this task as High priority.Mon, Jun 5, 6:16 PM
daniel lowered the priority of this task from High to Low.
daniel moved this task from Unsorted to Parsoid pile on the RESTbase Sunsetting board.