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-Former-Sprint-Board board.

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

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.

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

thiemowmde closed this task as Resolved.Jan 30 2017, 8:06 PM
thiemowmde moved this task from incoming to in progress on the Wikidata board.