Create Special:EntityPage to allow addressing entity pages without knowing the appropriate namespace
Closed, ResolvedPublic


Special:EntityPage should take an entity ID as a subpage parameter, e.g. Special:EntityPage/Q12345. Special:EntityPage will generate an HTTP redirect (status 303?) to the respective entity's page on that repo.

As a bonus, Special:EntityPage should support foreign entity ids as well. Special:EntityPage/foo:Q12345 would effectively redirect to foo:Special:EntityPage/Q12345 which would in turn redirect to Q12345 on the foo repo.

Rationale: client wikis (including federated repos) should have a way to link to an entity page without the need to know the namespace names of all entity types on the target wiki.

daniel created this task.Dec 16 2016, 9:33 PM
WMDE-leszek moved this task from Backlog to Doing on the Wikidata-Sprint board.

Change 330164 had a related patch set uploaded (by WMDE-leszek):
Add Special:EntityPage for addressing entities without knowing the namespace

WMDE-leszek moved this task from Doing to Review on the Wikidata-Sprint board.Jan 3 2017, 9:17 AM

There has been some discussion on about what HTTP response code should be used.

Initially code 303 has been proposed, as it is the response code used by Special:EntityData while performing content negotiation.
Use case of Special:EntityPage is slight different, though, i.e. there is not content negotiation, it is about providing a uniform way of linking to entity pages.
In the above-mentioned patch 301 has been suggested as a possible better response code choice.

HTTP 1.1 standard ( defines 301 as:

301 Moved Permanently

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.

wheres code 303 as:

303 See Other

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. The new URI is not a substitute reference for the originally requested resource. The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

Special:EntityPage is clearly not the primary use case of 303 - it is not about POST-requests forwarding.
In this regard 301 as a code specifying kind of alias seems closer of the intent behind Special:EntityPage. I am not completely certain about the "permanence" imposed in 301 definition. I guess it does not do much harm if clients learn URLs Special:EntityPage redirects to and use them directly but this is no something I have initially considered at all.

@Aleksey_WMDE @daniel: I am going to change the status code to 301 in the patch as it seems to be a slightly better choice in our case. I am not entirely convinced. I believe it might be worth to document any further discussion/consideration in the ticket here for possible future reference, so it is not buried in code review comments on Gerrit.

It is also a different use case but for the record: Wikidata's Concept URIs ( redirect to Special:EntityPage with status code 303.

thiemowmde moved this task from Review to Doing on the Wikidata-Sprint board.Jan 11 2017, 4:32 PM

Change 331842 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Reduce duplicate and not needed code in SpecialEntityPageTest

Change 330164 merged by jenkins-bot:
Add Special:EntityPage for addressing entities without knowing the namespace

Change 331842 merged by WMDE-leszek:
Reduce duplicate and not needed code in SpecialEntityPageTest

WMDE-leszek moved this task from Doing to Done on the Wikidata-Sprint board.Jan 17 2017, 1:39 PM
thiemowmde closed this task as Resolved.Jan 30 2017, 8:06 PM
thiemowmde moved this task from incoming to in current sprint on the Wikidata board.