Page MenuHomePhabricator

Audit MediaWiki redirect handling in summary, mobileapps, definition end points
Closed, ResolvedPublic

Description

The mobileapps service follows MediaWiki redirects internally, and returns responses corresponding to the final destination of those redirects. As a consequence, those responses are then stored under the original title.

However, those stored non-canonical resources are never updated thereafter.

To fix this, we need to handle redirects in a more consistent and careful manner.

Options

1) Generalize redirect handling in RESTBase

This option would implement redirect handling at a higher level, possibly based on title / revision information gathered as part of access checks.

2) Return redirect responses from clients

Another option is to return & store actual redirect (302) responses from services like mobileapps, and leave following those redirects to the client.

Event Timeline

I would prefer option 1. MW API has the ability to follow redirects, which the app takes advantage of. Anything less would be a step back.

@bearND, option 1 is what we are also moving towards with T118548. @Pchelolo has already implemented most of the generic redirect handling. We are now waiting for VE and content service to sent ?redirect=false parameters before we can deploy this in production.

@GWicke, https://gerrit.wikimedia.org/r/#/c/281989/ is merged, so the mobileapps side is covered in this regard. We can deploy that on Monday.
Should we still go forward with https://gerrit.wikimedia.org/r/#/c/281588 ? Would be great to have someone else review that as well. @Pchelolo would be a great candidate to review this since he's working on similar things in RB. Thanks.

@bearND I've +2 your redirect change. Let's deploy that one on Monday to mobile service, because switching to redirect processing in RESTBase would require a bit more work: we need to make VE add a redirect=no, make a public announcement as it's a drastic change, and then develop a patch for mobile service utilising the new RB functionality. Will take at least one more week, so deploying a quick-fix to mobile service is a good idea I think.

bearND claimed this task.