Page MenuHomePhabricator

What is a "content namespace" for purposes of the summary 2.0 endpoint?
Closed, ResolvedPublic


The summary 2.0 endpoint spec dictates that the server must return an empty 204 response to requests for summaries for pages outside the content namespace(s); "content namespace" is undefined. The service is currently hardcoded to return a 204 for any namespace other than the main namespace (namespace 0).

In principle, a wiki may configure any number of its namespaces as "content namespaces" via $wgContentNamespaces, and this designation will be client-retrievable via ApiSiteInfo.

In practice, most WMF production wikis define mainspace to be their only content namespace (see here for the full config setting—the file will take a minute to load and scroll to target).

Meanwhile, our intention appears to be to consider a broader range of namespaces (such as File) to constitute "content namespaces" for the purposes of the summary API.


  1. Keep the current logic in place (i.e., return a 204 for all requests outside namespace 0);
  2. Determine the wiki's content namespace(s) from siteinfo, and return summaries for any page in those namespaces (most often just 0 in practice);
  3. Hard-code a specific set of namespaces as "content namespaces" for purposes of the summary API.

Event Timeline

What are the use cases here?

For instance on commons the file namespace is a content namespace but it's not clear what a summary would look like for that.

Personally I'd like to work from use cases rather than hypothesize what might be useful. We've already identified that different projects may need different handling e.g. wikisource and wikidata spring to mind but I'd advise doing that on a per project basis rather than namespace. Also namespaces may be used differently on different projects so it would be dangerous to generalise...

As I mentioned during the Reading Infrastructure team weekly meeting, I think that this is best served by a whitelist with an initial value of [ NS_MAIN ]. I think it's fair to assume that we will want to add more namespaces moving forward, regardless of how we intend to process them.

I think this best aligns with option 3.

Change 385072 had a related patch set uploaded (by Mholloway; owner: Mholloway):
[mediawiki/services/mobileapps@master] Summary 2.0: Introduce namespace whitelisting

Sounds good! I don't have any use cases in mind for other namespaces at the moment. I think the whitelist idea will do nicely.

Change 385072 merged by jenkins-bot:
[mediawiki/services/mobileapps@master] Summary 2.0: Introduce namespace whitelisting

Mholloway claimed this task.