When requesting page content (e.g. mobile-sections-lead) for a page that is a redirect, the app expects to receive an HTTP 302 response, with a resolved location header, which tells our network library to automatically re-request the page with the resolved title.
In the general case, this seems to work correctly. However, when the app sets the Cache-Control header to be no-cache, the endpoint actually returns the body of the unresolved redirect page, without giving a 302 status, which is messing up some of our logic in the app.
The strange thing is that this doesn't happen every time.
For example, if you run the following curl command:
curl -v https://en.wikipedia.org/api/rest_v1/page/mobile-sections-lead/Obama
...it consistently gives a HTTP 302 status, which is what we expect.
However, if you run this curl command:
curl -v --header "Cache-Control: no-cache" https://en.wikipedia.org/api/rest_v1/page/mobile-sections-lead/Obama
...about 50% of the time it returns HTTP 302, but the other times it returns HTTP 200, with the actual content of the redirected page, which is not what we expect.
NB: the app uses the Cache-Control header for managing whether content should be cached locally vs. saved for offline use vs. forced to refresh from the network.